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The  logo  for  the  Navy  Standard  Software  Engineering  Environment 
(NSSEE)  shows  a  sea  serpent  riding  the  crest  of  the  software  technology 
wave  and  breathing  structure  into  the  software  development  process 
(represented  by  the  well-ordered  field  of  ones  and  zeros).  NSSEE  should 
be  pronounced  "Nessie"  in  honor  of  a  lake-dwelling  resident  of  the  British 
Isles.  History  does  not  record  any  interaction  between  Nessie  and  another 
well-known  British  citizen,  Ada.  The  modem  Ada  and  NSSEE  will  be  well- 
acquainted,  however. 


PREFACE 


This  is  one  of  a  set  of  documents  resulting  from  the 
work  of  the  Naval  Material  Command's  Software  Engineering 
Environment  Working  Group  (SEEWG).  The  set  includes  an 
■Executive  Summary,"  "Framework  for  a  Navy  Standard  Soft¬ 
ware  Engineering  Environment,"  and  "Evolution  Plan  for  a 
Navy  Standard  Software  Engineering  Environment." 

The  Framework  document  provides  a  basis  on  which  to 
plan  and  develop  a  standard  methodology-driven  software 
engineering  environment  for  the  Navy.  The  Evolution  Plan 
describes  a  strategy  for  transition  to  a  standard  software 
engineering  environment  and  also  the  evolution  of  the 
environment  itself. 

These  documents  represent  the  culmination  of  the  first 
phase  of  an  effort  to  develop  standard  tools  and  procedures 
to  support  development  of  software  for  Navy  embedded  computer 
systems.  It  is  intended  ultimately  to  implement  a  standard 
software  engineering  environment  encompassing  the  whole 
software  life  cycle  and  supporting  effective  use  of  the  Ada 
programming  language.  In  the  interim,  these  documents  will 
provide  a  basis  for  co-ordinating  decisions  with  respect  to 
improvements  to  existing  software  support  systems. 


FOREWORD 


This  document  contains  information  on  a  framework  for 
a  software  engineering  environment.  It  is  the  work  of  the 
NAVMAT  Software  Engineering  Environment  Working  Group 
( SEEWG ) .  The  SEEWG  studied  the  issues  of  what  is  the  life 
cycle  of  software,  what  is  a  software  engineering  process, 
what  is  a  software  engineering  environment,  and  what 
methodologies,  tools  and  techniques  are  applicable. 

The  Framework  is  based  primarily  on  "Software  Engi¬ 
neering  Environments  for  Navy  Embedded  Computer  Systems," 
February  27,  1982,  prepared  for  NAVSEA  61R  by  Software 
Architecture  and  Engineering,  Inc.,  Arlington,  Virginia. 

Other  documents  used  for  source  information  include: 

1.  Top  Level  Requirements  for  Navy  Minimum  Ada 
Programming  Support  Environment,  4  December  1981. 

2.  The  Software  Functional  Description  for  the  Software 
Production  Facility  of  the  NAVELEX  C3  Software 
Support  Facility,  29  September  1981,  Software  and 
Computer  Directorate,  Naval  Air  Development 
Center,  Warminster,  Pennsylvania. 
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EXECUTIVE  SUMMARY 


The  Software  Engineering  Environment  Working  Group 
(SEEWG)  was  established  by  the  Chief  of  Naval  Material 
(MAT  08Y )  on  April  27,  1981.  Its  purpose  was  to  coordinate 
current  and  planned  software  engineering  environment  (SEE) 
initiatives  in  the  naval  systems  commands  to  ensure  that 
they  are  well  integrated  and  non-redundant.  Further,  it 
was  to  provide  a  NAVMAT  focal  point  for  addressing  software 
engineering  environment  issues  and  to  coordinate  action  on 
critical  SEE  related  efforts. 

The  specific  objectives  defined  in  the  SEEWG  charter 

were: 

A.  Provide  a  focal  point  for  SEE  activities  within 
the  Naval  Material  Command  (NAVMAT). 

B.  Coordinate  current  and  planned  SEE  projects 
within  NAVMAT  to  ensure  consistency,  compati¬ 
bility,  and  non-redundancy  of  effort. 

C.  Develop  a  specification  for  Navy  SEEs  that 
is  based  on  the  Navy  Minimum  Ada  Programming 
Support  Environment  (MAPSE). 

D.  Guide  the  assimilation  and  integration  of 
standard  SEEs  into  the  Navy  software  develop¬ 
ment  process. 

.  •  ^  / 

The  working  group  formed  to  address  these  objectives  > 
was  composed  of  designated  managers  and  technical  experts  X. 
from  naval  systems  commands  and  field  activities  (listed  in 
Appendix  A).  In  addition,  the  SEEWG  obtained  contracted 
support  from  Software  Architecture  and  Engineering,  Inc. 
(formerly  Lesko/Fox  Associates)  of  Arlington,  Virginia. 

A  series  of  meetings  was  held  to  address  the  technical, 
programmatic,  and  policy  issues. 

The  objective  of  providing  a  focus  for  Navy  software 
engineering  initiatives  has  been  achieved. 

The  SEEWG  members  themselves  represent  a  number  of 
the  principal  software  engineering  projects  within  the 
Navy.  Their  common  effort  to  define  the  nature  of  a  stan¬ 
dard  software  engineering  environment  tor  the  Navy 
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has  received  significant  recognition  in  both  the  Navy 
software  development  world  and  in  industry.  Momentum 
towards  a  new  software  engineering  process  for  the  Navy 
has  been  created  which  can  be  exploited  to  assure  the 
development  and  introduction  of  new  tools  and  techniques 
which  have  been  identified  as  needed.  NAVMAT  and  a  re¬ 
chartered  SEEWG  will  manage  this  process  to  capitalize  on 
the  progress  thus  far. 

The  objectives  of  developing  requirements  for  a  MAPSE- 
based  software  engineering  environment  is  addressed  in  the 
SEEWG  report  "Framework  for  a  Navy  Standard  Software 
Enginering  Environment."  It  should  be  noted  that  the 
Framework  proposed  is  preliminary  to  formal  specification 
of  requirements  for  acquisition  purposes. 

The  objectives  of  guiding  assimilation  and  integration 
of  standard  SEE's  into  the  Navy  software  development  process 
has  been  addressed  both  in  the  Framework  document  and  in 
the  "Evolutiori  Plan  for  a  Navy  Standard  Software  Engineering 
Environment. This  SEEWG  product  deals  specifically  with 
the  transition  process  from  the  current  situation  to  the 
future  standard  SEE  and  also  with  subsequent  technological 
innovation.. 

Thus,  -'\he  two  tangible  products  of  the  SEEWG  effort 
are  the  Framework  and  Evolution  Plan  documents.  The  main 
conclusions  of  each  are  summarized  as  follows.^ 


Framework  for  a  Navy  Standard  Software  Engineering  Environment 


-  The  software  engineering  environment  must  support 
the  entire  software  life  cycle.  A  life  cycle  model 
has  been  developed  in  which  to  view  software  devel¬ 
opment  as  an  incremental  process. 

-  The  software  engineering  environment  must  be 
methodology-driven.  A  collection  of  tools  is  of 
little  benefit  in  the  absence  of  an  integrating 
discipline  for  their  employment. 

-  The  tools  and  techniques  to  support  each  activity  in 
the  software  life  cycle  have  been  identified. 


til  * 
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The  information  products  derivable  in  each  activity 
of  the  life  cycle  have  been  categorized  according  to 
whether  the  information  must  be  baselined  in  the 
software  engineering  environment  data  base  or  not. 
Baselined  products  are  configuration  managed  and 
persist  over  the  life  of  the  software  system  being 
developed.  Thus,  the  nature  of  the  environment's 
data  base  is  fundamental  to  the  choice  of  tools 
provided  and  to  the  integrating  discipline  for  their 
employment. 


Evolution  Plan  for  a  Navy  Standard  Software  Engineering 
Environment: 


-  The  Navy  Standard  Software  Engineering  Environment 
(NSSEE)  will  be  based  on  the  Minimum  Ada  Programming 
Support  Environment  (MAPSE).  The  MAPSE  provides  the 
best  foundation  upon  which  to  build  a  fully-integrated 
software  engineering  environment. 

-  Existing  Navy  application  projects  and  support  sys¬ 
tems  cannot  be  ignored  and  should  be  able  to  gain 
some  benefit  from  the  concepts  and  products  resulting 
from  the  definition  and  development  of  the  NSSEE. 

An  approach  is  described  to  assure  the  smooth 
transition  to  a  modern  Navy  Standard  Software  Engi¬ 
neering  Environment. 

-  The  Navy  must  build  at  least  one  integrated  tool  set 
that  will  operate  through  all  phases  of  the  life 
cycle  model.  The  availability  of  such  a  Navy  Stand¬ 
ard  Software  Engineering  Environment  and  the  control 
afforded  by  the  baselining  of  standardized  informa¬ 
tion  products  will  greatly  improve  the  Navy's  ability 
to  manage  the  acquisition  and  maintenance  of  effective 
software  systems  at  reduced  life  cycle  costs. 

-  Current  policies,  standards,  and  guidelines  need  to 
be  changed  in  order  to  provide  a  framework  within 
which  a  NSSEE  can  be  built  and  used.  Evolution  of 
these  policies,  standards,  and  guidelines  will  be 
necessary  as  the  Navy  Standard  Software  Engineering 
Environment  evolves. 
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-  Training/education  is  extremely  important  for  man¬ 
agers,  developers,  and  users  of  the  NSSEE.  Under¬ 
standing  how  to  use  the  Navy  Standard  Software 
Engineering  Environment  competently  is  crucial  to 
deriving  any  benefits  from  it. 

-  The  need  for  a  research  and  development  effort  is 
identified  to  ensure  the  timely  maturing  of  software 
technology  to  support  full  implementation  of  the 
desired  Navy  Standard  Software  Engineering  Environ¬ 
ment. 

Perhaps  the  most  important  result  of  the  SEEWG  effort, 
however,  may  be  the  attention  it  has  drawn  to  the  need  for 
a  standard  software  engineering  process  to  support  the 
effective  use  of  the  Ada  programming  language  in  Navy 
applications.  Momentum  for  a  modern  Navy  Standard  Software 
Engineering  Environment  (NSSEE)  has  been  gathered.  Action 
by  NAVMAT  will  now  be  taken  to  see  that  the  SEEWG  recommen¬ 
dations  give  rise  to  actual  specifications  for  a  NSSEE 
and  to  policies  and  standards  appropriate  to  support  it. 


t 


APPENDIX  A 
SEEWG  MEMBERSHIP 


LCDR  K.  Paige  (Co-chairman) 
CDR  R.  Simpson  (Advisor) 

CDR  A.  Hadley  (Advisor) 

LCDR  J.  Kramer 

R.  Eyres 

H.  Stuebing 
CDR  R.  Goodman 
J.  Blackmon 
T.  Conrad 
LCDR  J.  Barnes 
D.  Jordan 
LTCOL  A.  Hesser 
T.  Phillips 

S.  Peele 

P .  Andrews 
J .  Machado 

B.  Zempolich 

T.  Dawson  (Recorder) 

R.  Charette 

C.  Russ 
Sa.lraer 
Li  n  ley 

.  Potter 
W.  v;*  v.ier 

' 1  ■  ■  •  ■  *  \  O  *  e.  *'•  ■  i  ,! 


PMS  408 
OP- 94 2 
OP-942 

MAT  08Y/AJPO 

NOSC 

NADC 

PMS  408 

PMA  533 

NUSC 

NAVELEX  (ELEX-814) 

PME  120-3 
Marine  Corps 
NOSC 

FCDSSA  Dam  Neck 
NAVSEA  (SEA  61R) 
NAVELEX  (ELEX  6134) 
NAVAIR  (AIR  360B ) 

NUSC 

NUSC 

FCDSSA  Dam  Neck 
FCDSSA  San  Dieqc 
NAC 

NAVELEX  ; ELEX-814 ) 

NSWC ,  Dahlgren 

So  5  t  wart  '  r  cii  i  r  e-ot  ure  ; 


J 


FRAMEWORK 

FOR  A  NA V  /  STANDARD 
SOFT'.*  ART  ENGINEERING 

FNVIRCNMENT 


SOFTWARE  ENGINEERING  ENVIRONMENT 

WORKING  GROUP 


March  31,  1982 


The  logo  for  the  N  :  '  Standard  Software  Engineering  Environment 
(NSSEE)  shows  a  sea  serpent  riding  the  crest  of  the  software  technology 
wave  and  breathing  struct  u>  _•  into  the  software  development  process 
(represented  by  the  well-ordered  field  of  ones  and  zeros).  NSSEE  should 
be  pronounced  "Nessie"  in  honor  of  a  lake-dwelling  resident  of  the  3ntish 
Isles.  History  does  not  record  any  interaction  between  Nessie  and  another 
well-known  3ritish  citizen,  Ada.  The  modem  Ada  and  NSSEE  will  be  well- 
acquainted,  however. 


PREFACE 


This  is  one  of  a  set  of  documents  resulting  from  the 
work,  of  the  Naval  Material  Command's  Software  Engineering 
Environment  Working  Group  ( SEEWG ) .  The  set  includes  an 
■Executive  Summary,"  "Framework  for  a  Navy  Standard  Soft¬ 
ware  Engineering  Environment,"  and  "Evolution  Plan  for  a 
Navy  Standard  Software  Engineering  Environment." 

The  Framework  document  provides  a  basis  on  which  to 
plan  and  develop  a  standard  methodology-driven  software 
engineering  environment  for  the  Navy.  The  Evolution  Plan 
describes  a  strategy  for  transition  to  a  standard  software 
engineering  environment  and  also  the  evolution  of  the 
environment  itself. 

These  documents  represent  the  culmination  of  the  first 
phase  of  an  effort  to  develop  standard  tools  and  procedures 
to  support  development  of  software  for  Navy  embedded  computer 
systems.  It  is  intended  ultimately  to  implement  a  standard 
software  engineering  environment  encompassing  the  whole 
software  life  cycle  and  supporting  effective  use  of  the  Ada 
programming  language.  In  the  interim,  these  documents  will 
provide  a  basis  for  co-ordinating  decisions  with  respect  to 
improvements  to  existing  software  support  systems. 


FOREWORD 


This  document  contains  the  executive  summary  of  tr.e 
work  done  by  the  NA7MAT  Software  Engineering  Environment 
Working  Group  (GEEWG).  For  the  past  year,  the  members  of 
the  SEEWG  have  been  grappling  with  the  issues  of  what  a 
software  engineering  environment  is,  what  an  environment 
contains,  now  to  acquire  one  that  meets  the  Navy's  needs, 
and  how  to  deal  effectively  with  the  transition  to  the  new 
software  engineering  technology. 
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INTRODUCTION 


The  Software  Engineering  Environment  Working  Group 
( SEEWG )  was  created  by  the  Naval  Material  Command  {NAVMAT) 
in  April  of  1981.  Its  purpose  was  to  develop  a  strategy 
for  software  engineering  environments  in  the  Navy.  The 
goal  of  the  SEEWG  was  to  eliminate  the  duplication  of 
effort  in  support  systems  for  software  development  and  to 
improve  software  development  productivity  and  the  relia¬ 
bility  of  software.  Specifically,  its  objectives  were: 

1.  To  provide  a  focal  point  for  SEE  activities  within 
NAVMAT. 

? .  fo  coordinate  current  and  planned  SEE  projac*:^  to 
ensure  consistency,  compatibility  and  ncv. ••  k,n~ 

dancy  of  effort. 

.> .  To  guide  the  issimi  lac  ion  and  integration  of 

standard  SESs  into  the  Navy  software  development 

process. 

4.  To  develop  a  specification  for  Navy  SEEs  that  is 
based  on  the  Navy  Minimum  Ada  Programming  Support 
Environment  (MAPSE). 


X.l  Purpose  of  the  Framework 


The  Framework  section  presents  the  standard  SEE  in 
terms  of  the  methodologies  and  tools  required  to  support 
the  Navy's  software  life  cycle  management.  It  is  prelim¬ 
inary  to  developing  a  formal  specification  of  SEE  require¬ 
ments  for  acquisition.  It  will  provide  some  ground  rules 
and  a  focus  for  the  Navy's  SEE  efforts,  both  long  and 
short  term. 

Part  I  of  the  Framework  outlines  a  well-defined  doc¬ 
trine  for  the  software  engineering  discipline.  This  pro¬ 
vides  a  context  for  the  Navy  SEE  framework. 

Part  II  defines  the  characteristics  of  a  SEE.  Some 
cacxgrcund  ;r.  '.he  state-of-the-art  practice  of  software 
. me  Navy  is  provided  x.n  Appendix  A  of  the  Framework . 

The  background  information  suggests  t.ne  rationale  for  a 
SEE  program. 
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The  Navy  will  oenefi;  from  start  mg  <  pro-gram  to  imp!  •— 
ment,  in  a  standard  manner  across  the  •/,  some  ■■■,£  the 
coven  software  engineering  methcdo log :~s  and  t  oo  1 3  .  Th  e  :.  r 
ntroduction  will  begin  to  prepare  Navy  personnel  :  _  r  tie 
Navy  standard  SEE.  it  w*  1  help  t:  improve  software  re;  : 
bility  and  the  productivity  of  software  ie ve lopmeo t .  ft 
will  also  begin  standai Jicat ion  o:  prod not  forms  at  the 
activity  interface  points  described  in  Section  1.4. 

More  research,  analyses  and  development  is  needed  to 
improve  the  lass  well  understood  me t.hcdo  Logies ,  techniques 
and  tools  of  software  engineering.  The  framework  identifies 
a  tanner  of  these  items  sc  -hat  additional  work  tar.  be  j  i  r. 
to  meet  Navy  requirements.  These  can  or  i  ir. reduced  to  Navy 
personnel  as  they  are  refined  and  become  available  Car  nee. 
c.'; .  !  rg  t  v.g  technologies  such  as  knowledge- bn  sed  expert  cm  ems 
are  expected  to  find  mar./  applications  o  it  the  technology 
ij  still  undeveloped. 

V*1  ’  v  document  i<  intended  for  a  wide  audience  in  the 
"ho  r,\ .’MAT  p  1  a Tiir.g  and  policy  hierarchy  should  v: 
i-i  a  for  software  engineer  ..ng  planning  arc  star 

a .Is  rede  fin  it  Ion.  support  software  production  groups 
>  wifi  locus  or.  the  software  engineering  process,  meth'dclc- 
ji  and  tools  outlined  to  guide  their  short-term  decisions 
m  sapport  system  upgrades.  Acquisition  managers  should 
,e  using  the  document  to  guide  procurement  decisions  relat¬ 
ing  to  software  engineering  and  software  engineering  envi¬ 
ronments  . 


1 . 2  Background 


The  current  state  of  software  engineering  practice  in 
the  Navy  exhibits  a  number  of  serious  weaknesses;  the 
basic  concepts  reflected  in  the  Framework  are  intended  to 
counter  tr.ese  practices.  Three  points  summarize  the 
situation  discussed  more  fully  in  Appendix  A': 

Variation  in  Practice  -  There  is  a  wide  range  of 
software  engineering  practices  within  the  Navy  and 
among  its  contractors.  These  practices  lag  the 
state-of-the-art  by  as  many  as  fifteen  years.  The 
same  variation  is  evident  in  the  support  systems 
used. 
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As  a  result,  software  is  difficult  to  manage,  sett- 
ware  products  vary  widely  in  cost,  reliability  and 
maintainability,  and  it  is  extremely  difficult  to 
introduce  advances  in  technology  on  a  Navy-wide 
basis  to  improve  either  productivity  or  the  overa.  1 
quality  of  the  software. 

Need  to  Increase  Productivity  -  Based  on  the 
analysis  of  projected  work  loads,  the  demand  for 
software  will  soon  outstrip  the  resources  available 
for  producing  software.  This  is  a  potential  threat 
to  fleet  readiness.  The  only  viable  answer  is  to 
increase  productivity,  which  can  only  be  accomplished 
on  the  scale  required  by  increasing  the  productivity 
of  the  process  as  a  whole. 

Need  for  Focus  -  One  way  to  increase  productivity  is 
to  improve  the  methodologies  and  tools  used  by  the 
production  groups.  The  Navy  has  a  large  number  of, 
as  yet,  uncoordinated  efforts  to  modernize  its  sup¬ 
port  systems.  These  efforts  must  be  better  focused 
to  make  a  significant  impact  on  both  productivity 
and  quality. 


1.3  Guiding  Principles 


The  Framework  provides  a  means  to  improve  the  current 
situation.  The  Framework  was  created  with  several  funda¬ 
mental  principles  driving  the  work.  These  principles 
should  be  kept  in  mind  when  reading  this  document.  They 
ares 


Based  on  Navy  MAPSE  -  The  Navy  SEE  must  be  consis¬ 
tent  with  the  Navy  MAPSE.  The  SEE  must  include 
full  support  for  Ada  plus  an  integrated  data  base. 

It  must  also  provide  continuing  support  for  existing 
Navy  standard  programming  languages. 

Methodology-Based  -  The  software  engineering  process 
and  its  related  methodologies  are  the  foundation  for 
the  SEE  and  its  methodologies  and  tools.  The  entire 
life  cycle  of  software  is  included  in  the  software 
engineering  process.  Each  methodology  is  related  to 
specific  activities  of  the  process.  The  methodologies 
and  tools  are  divided  into  those  that  support  crea- 
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ttvity  and  these  that  support  the  recording  of  prod 
ucts.  (The  importance  of  splitting  creativity  and. 
recording  is  discussed  in  Part  T . 1  The  concept  of 
having  formal  !■'  *  ■  fuoes  uefined  far  ea< 
e  n  ;  ’  •  eerie  j  no  •.  v  if-  is  fun  da"  :*n  t  ’1  to 


sot  ware 

i  a  -J  4  t  o 
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•or  <  1  }3d  e 
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one  :'f  t.ne  first  pr: 'rules  ci  tr.e  Navy  see  program, 
i;  identified  :v  tr.e  SEEWG  ,  a  the  *  ar.da  rd  i  z  a  1 1  or.  ;f  tr.e 
firm  of  software  ar.u  its  supporting  i  nf  nrma  t  ion  products. 
Software  should  ce  t  ranspertab I  e  at  minimum  rest  cetweer. 
one  support  group  ard  environment'  to  another  support 
group  (and  possibly  a  different  er.  v  i  r  onme.nt  :  .  This  stand¬ 
ardization  will  be  achieved  oy  defining  tr.e  formal  inter¬ 
faces  between  software  life  cycle  activities,  as  defined  i 
Part  I  Sect  ion  1.2. 

The  concept  of  formal  interfaces  is  sr.cwn  m  Figure 
Software  production  and  Life  cycle  support  can  ce 
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divided  into  two  activities:  software  generation  and  the 
control  of  software  generation.  Software  generation  con¬ 
sists  of  the  four  activities  defined  in  Part  I:  require¬ 
ments  analysis,  specification,  design  and  implementation. 
"Interfaces"  between  activities  are  the  baselined  products 
created  for  the  activity.  These  "interface"  products  are 
used  by  others  to  work  toward  the  creation  of  the  final 
software  product. 

The  two  activities  of  software  generation  control 
are  correctness  analysis  and  management.  The  "interfaces" 
between  the  control  activities  and  the  software  generation 
activities  are  a  variety  of  plans  and  measurements,  most 
of  which  are  baselined  products. 

The  baselined  products  that  are  the  formal  interfaces 
are  defined  in  Part  II  Section  1.1.1.  Several  of  these 
products  are  identified  in  Figure  1.3-1.  Specifications 
for  these  formal  interfaces  will  be  part  of  the  SEE  pro¬ 
gram.  These  specifications  will  define  the  form,  content 
and  physical  configuration  of  interfaces,  which  will 
simplify  moving  them  from  one  environment  to  another. 

The  SEE  will  have  standard  tools  and  procedures  to 
record  the  interfaces.  These  standard  tools  will  be  for 
recording  the  products.  They  will  not  preclude  the  use  of 
additional  tools  and  procedures  for  the  creative  aspects 
of  arriving  at  the  definition  of  these  baselined  products. 
Such  an  approach  allows  variation  and  innovation  in  the 
creative  aspects  of  the  software  engineering  process  while 
standardizing  the  form  of  the  recorded  products. 

This  document  defines  the  six  life  cycle  activities 
shown  in  Figure  1.4-1.  It  also  describes  the  nature  of 
the  baselined  products  for  which  formal  interface  speci¬ 
fications  will  be  developed.  These  interface  specifications 
will  be  the  subject  of  a  future  document. 


1.5  Structure  of  the  Framework 


This  Framework  is  divided  into  two  major  parts: 

Part  I  descrices  a  well-defined  doctrine  of  software 
engineering  disciplines,  including  the  methodologies 
and  activity-specific  tools  vital  to  it.  This  is 
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the  foundation  for  the  Navy  Si..",  as  defined  in  Pert 
II,  and  -is  it  will  evolve  witn  experience  and  the 
advances  of  technology. 

Pert.  II  defines  the  characteristic?  of  a  GEE  as 
an  integrated  system  consisting  of  a  computer-based 
support  system  and  data  base. 

Appendix  A  provides  some  background  on  tne  problems 
acing  the  Navy  in  software  development.  The  SEEV^G  was  a 
irect  outgrowth  of  the  forecasts  summarized  in.  Appendix  A, 

A  glossary  is  provided  to  define  the  terms,  phrases, 
nd  acronyms  used  within  this  document.  It  is  rot  of  fe  red 
s  a  standard  for  terminology  within  the  Navy  or  •ndustry. 

Tne  heading  for  each  pace  of  the  document  guides  the 
eador  by  telling  them,  to  four  levels  of  indexing,  the 
art  of  the  document  being  read.  The  page  number  tells 
he  major  section  being  read  (where  s  is  Part  I,  Part 
II,  Appendix  A.,  Glossary  or  Index)  and  the  page  number. 

Up  to  four  levels  of  title  will  be  given;  the  titles  are 
either  full  or  slightly  shortened. 


Page  s-##  Section  a.b.c.d.  Title  "a":  Title  *b“ 

Title  "c":  Title  "d" 
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approach  tar.not  address  the  Navy's  problems  in  software 
development.  A  software  engineering  environment  must  be 
seen  as  ar:  integrated  data  base  and  support  system;  it  will 
■ace  a  ■•■■e  1  i-de :  ined  software  engineering  process  and  associ¬ 
ated  methodologies  far  more  effective.  With  a  comprehensive 
uES  supporting  a  well-defined  process  and  methodologies, 
the  Navy's  software  production  groups  should  greatly  improve 
their  productivity  as  well  as  the  reliability  of  their  soft¬ 
ware  . 


Before  the  requirements  for  a  SEE  can  be  presented, 
the  doctrine  underlying  a  software  engineering  environment 
must  be  clearly  defined.  It  would  be  unwise  to  design 
tools  for  building  a  house  without  understanding  the  process 
of  building  houses.  Similarly,  one  should  not  try  to  design 
a  SEE  without  first  clearly  defining  the  software  engineer¬ 
ing  process.  Therefore,  Part  I  describes  a  comprehensive 
software  engineering  process  and  its  associated  methodologies 
so  that  a  comprehensive  SEE  supporting  it  can  be  described 
in  Part  II. 

Simply  defined,  a  software  engineering  process  is  a 
set  of  activities  for  developing  and  modifying  software 
through  its  life  cycle.  This  process  becomes  the  framework 
for  a  set  of  consistent  software  engineering  methodologies. 

A  methodology  is  a  repeatable  human  procedure  which  supports 
some  aspect  of  an  activity.  A  well-conceived  methodology 
separates  the  creative,  intellectual  aspects  of  an  activity 
from  the  clerical,  mechanical  aspects.  A  tool  is  a  computer- 
based  aid  which  stimulates  the  creative,  intellectual  pro¬ 
cesses  or  automates  the  clerical  processes. 

Some  may  take  exception  to  the  methodologies  selected 
but  this  is  to  be  expected  in  any  new  field.  These  method¬ 
ologies  reflect  good  software  engineering  as  it  is  known 
today  and  were  chosen  because  they  satisfy  certain  criteria: 

-  They  improve  the  effectiveness  and  productivity  of 
software  development  activities. 


-  They  result  in  the  creation  of  more  reliable  software. 


Page  1-2 


*  * 


Part  I  Context  of  Software 


r,g  i  nee  ring 


-  They  fit  together  to  form  an  integrated  set  of  method¬ 
ologies. 

-  They  separate  the  creative  aspects  of  software  devel¬ 
opment  from  its  more  mechanical  aspects. 

-  They  promote  the  automation  of  the  clerical,  mechan¬ 
ical  aspects  of  software  development. 

A  good  SEE  requires  a  comprehensive  set  of  methodolo¬ 
gies.  The  implementors  of  a  software  engineering  environ¬ 
ment  should  include  many  methodologies,  including  some  not 
covered  in  this  document.  However,  the  implementors  should 
be  guided  in  their  selection  by  the  criteria  listed  above. 


1.  Life  Cycle  Model 


The  life  cycle  model  of  a  software  system  depicts  the 
activities,  and  the  relations  among  these  activities, 
involved  in  the  development,  operation  and  life  cycle 
support  of  the  system  from  its  conception  to  its  retirement. 
Figure  1-1  provides  a  graphic  representation  of  the  life 
cycle  of  software  (Fox  [82]).  In  software  engineering,  the 
distinction  between  development  and  continuing  adaptation 
(often  referred  to  as  maintenance)  is  arbitrary,  depending 
when  the  first  release  begins  operation.  New  releases, 
based  on  changes  to  the  system,  periodically  upgrade  the 
operational  system. 

The  focus  of  the  SEE  description  will  be  the  develop¬ 
ment  and  continuing  adaptation  segments  of  the  life  cycle. 
Some  operational  requirements  on  the  SEE,  such  as  perfor¬ 
mance  monitoring,  will  also  be  discussed.  The  following 
activity  categories  for  software  development  have  been 
selected: 

Requirements  Analysis  -  Definition  and  analysis 
of  the  user's  evolving  needs. 

Specification  -  Translation  of  requirements  into 
a  precise  description  of  the  externals  of  the  soft¬ 
ware  system. 

Design  -  Creation  of  an  abstraction  of  a  software 
system  that  is  consistent  with  the  speci f ica t ion 
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Conception 
of  Software 


Software  Retirement 

Operational  0f  Software 


Development 


Continuing  Adaptation 


Figure  1-1:  The  Life  Cycle  of  Software 
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and  provides  a  reasonable  description  for  implemen¬ 
tation. 

Implementation  -  Creating  a  software  system  which 
implements  the  design. 

Correctness  Analysis  -  Determining  the  correctness 
of  each  product  of  the  software  development  process. 

Management  -  Planning,  organizing,  operating,  monitor- 
ing  and  controlling  all  activities  within  the  software 
development  process  with  the  objective  of  meeting 
pre-established  goals. 

Although  people  have  named  and  defined  these  categories 
differently,  the  real  difference  arises  from  the  relations 
among  the  categories.  These  relations  must  be  defined  to 
achieve  the  best  productivity  possible  while  creating  the 
most  reliable  software  possible. 


1.1  A  Current  Life  Cycle  Model 


Figure  1-2  shows  a  simplified  version  of  a  common  life 
cycle  model.  The  activity  categories  shown  do  not  match 
those  defined  in  the  previous  section,  but  they  map  roughly 
as  follows: 

Activities  Current  Model 


Requirements  Analysis 

Specification 

Design 

Implementation 


Requirements 

Functional  Design 

Detail  Design 

Code  and  Unit  Test 
Integration 

System  Test 


Correctness  Analysis 
Management 


(No  match) 
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Figure  1-2:  A  Current  Life  Cycle  Model 
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"here  are  many  versions  of  Figure  1-2,  sometimes  tailed 
tne  "waterfall"  model.  Some  models  use  activity  cate-jcr.es 
strictly  tied  to  certain  standards,  others  nave  vent  i  cat  i  or. 
feedback  loops,  but  they  show  some  or  all  ot  tne  foil  cw :  r,q 
snort comings : 

"mite  Activity  Phases  -  Management  assumes  activ¬ 
ities  have  distinct  beginnings  and  endings.  AlthOi.gr; 
tn.s  notion  is  appealing  to  management,  tne  actial 
technical  work  involves  a  continuing  iteration  ; f 
r  :c  .  .  r  :•  merits  analysis,  specification,  fesign,  imple¬ 
ment  a  - l on ,  and  correctness  analysis  over  tne  life 
oyc.e  of  a  software  system.  In  a  luge  pro;ect,  tne 
management  view  is  imposed  on  the  designers,  thereby 
restricting  the  iterative  process.  Perhaps  this  is 
why  a  small  design  and  implementation  group  is 
better  at  creating  quality  systems  on  schedule  and 
within  cost. 


Static  Requirements  -  Requirements  are  treated  as 
though  complete  definition  is  possible  early  in  the 
development  phase,  and  as  though  no  further  changes 
will  occur.  Nothing  could  be  farther  from  the  truth. 
Requirements  rarely  are  understood  fully  at  the 
start  of  software  development,  and  the  evolving 
nature  of  the  surrounding  systems  often  lead  to 
changes  in  requirements. 

"Big  Bang"  Psychology  -  Software  system  development 
Ts  seen  as  leading  to  the  creation  of  a  monolithic 
system.  For  large  systems  this  requires  coordinating 
the  work  of  many  programmers  over  extended  periods 
with  changing  requirements.  Such  an  approach  has 
consistently  resulted  in  overruns  in  schedule  and 
budget  and  poor  quality  software. 


Testing  as  the  Primary  Means  of  Correctness 
Analysis  -  Testing  is  the  traditional  way  to  per¬ 
form  correctness  analysis.  Because  testing  occurs 


late  in  the  development  phase,  the  majority  of 
errors,  which  are  introduced  in  the  earlier  activi¬ 


ties,  are  very  costly  to  correct  (Boehm  [76]). 


Correctness  analysis,  in  addition  to  testing,  must 
use  other  techniques  to  find  and  eliminate  errors  as 
they  occur.  Such  an  approach  could  greatly  reduce 


software  costs  and  improve  reliability. 
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the  waterfall  model  is  management. 

1.2  A  Recommended  Life  Cycle  Model 

Tour  '.dean  are  recommended  to  remedy  the  shortcomings 
of:  current  life  cycle  models: 

Incremental  development 

Early  prototyping 

Extended  correctness  analysis 

-  Management  integration 

Many  development  groups  in  industry  have  success- fuiy 
used  some  of  these  concepts.  The  effective  use  or  all 
four  could  have  a  dramatic  impact  on  software  quality  and 
productivity. 


1.2.1  Incremental  Development 


Incremental  development  can  reduce  the  disruptions  on 
the  developing  system  caused  ay  changing  requirements.  It 
also  increases  management  insight  and  control.  The  concept 
has  been  described  in  different  forms  (Mills  [7o;)  and 
(Basili  [75]).  The  basic  idea  is  to  build  a  software 
system  in  mall,  manageable  increments,  where  each  new 
. ncrement  is  a  new  system  with  additional  function.  The 
t  ir.'t  system  release  of  a  large  project  would  consist  of 
-a-',  increments. 
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Figure  1.2. 1-1  shows  a  life  cycle  model  based  on 
incremental  development.  It  is  similar  to  the  waterfall 
model  shown  in  Figure  1-2  through  requirements  analysis, 
specification  and  design.  Whereas  the  waterfall  model 
continues  into  code,  integration  and  test  of  the  first 
release  as  a  single  production  item,  the  incremental  devel¬ 
opment  model  proceeds  to  successive  increments.  Each  incre¬ 
ment,  as  shown  in  Figure  1.2. 1-2,  is  analogous  to  the  com¬ 
plete  waterfall  model.  Each  reiterates  requirements  analy¬ 
sis,  specification,  and  design  to  the  degree  necessitated 
by  changes  which  occur  at  the  base  level  since  the  last 
increment,  or  which  results  from  the  operational  experience 
of  previous  increments.  If  no  such  changes  have  occurred, 
the  increment  consists  of  design  elaboration,  implementa¬ 
tion,  correctness  analyses,  and  management  only. 

Using  incremental  development,  it  is  not  necessary  to 
have  a  consistent  complete  set  of  software  system  specifi¬ 
cations  and  design  before  the  start  of  implementation. 
Because  refinement  and  elaboration  of  these  "front  end" 
products  are  formally  built  into  each  increment,  a  natural 
framework  for  evolution  is  provided.  Therefore  it  is  neces¬ 
sary  to  perform  initial  requirements  analysis,  specification 
and  design  to  the  degree  sufficient  to  plan  for  development 
of  Release  1  and  to  begin  increment  1,  but  "complete"  defi¬ 
nition  is  not  required  until  the  last  increment  of  Release  1 

By  dividing  each  system  release  into  several  incre¬ 
ments  (6-8  months  in  duration),  management  of  change  is  pos¬ 
sible  in  a  controlled,  efficient  manner.  Estimation,  which 
is  usually  based  on  metrics  spanning  the  entire  development 
phase  can  be  calibrated  at  the  end  of  each  increment  allow¬ 
ing  for  early  detection  and  correction  of  schedule  or 
resource  changes. 

In  summary,  incremental  development  provides  the  fol¬ 
lowing  benefits  which  are  not  possible  with  the  current 
view  of  the  software  life  cycle: 

It  allows  for  early  verification  of  estimates 
for  development  resource. 

It  provides  a  framework  for  the  non-disruptive 
evolution  of  requirements. 


It  provides  better  insight  into  the  system  and 
application  during  development. 
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baseline*  control.  The  designer's  or  programmer's  view  of 
a  development,  although  constrained  by  the  management,  view, 
r.as  another  dimension.  Within  an  increment,  a  designer  may 
go  through  many  iterations  of  specification,  high- level 
design,  and  detailed  design  before  completing  the  work. 

This  gives  rise  to  two  different  sets  of  methodologies. 

One  set  supports  the  creative  aspects,  and  the  other  records 
the  result.  We  will  return  to  a  discussion  of  this  impor¬ 
tant  distinction  in  Section  2. 


1.2.2  Early  Prototyping 


Early  prototyping  fits  well  in  a  life  cycle  model 
based  on  incremental  development.  A  typical  Embedded  Com¬ 
puter  System  (ECS)  software  development  activity  might 
involve  as  few  as  three  and  as  many  as  five  or  six  incre¬ 
ments  during  development  of  the  first  release.  If  the 
first  increment  is  well  designed  and  well  planned,  it  can 
be  tested  as  a  prototype  to  evaluate  ill-defined  or  risky 
requirements.  In  general,  prototyping  will  require  special 
tools. 


Early  prototyping  can  be  enhanced  by  executable  design 
and  throwaway  code.  Executable  design  languages  could 
shorten  the  time  needed  to  produce  a  working  prototype. 
Throwaway  code  is  temporary  code  written  to  create  some 
needed  function  for  the  earliest  increments  of  the  system. 
The  use  of  throwaway  code  is  like  breadboarding  in  hardware 
development.  It  applies  the  Brooks'  dictum:  "plan  tc 
throw  the  first  one  away"  (Brooks  [75]). 
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1.2.3  Extended  Correctness  Analysis 

Figures  1.2. 1-1  and  1.2. 1-2  show  correctness  analysis 
extending  throughout  development.  Studies  have  shown  that 
50-80%  of  all  errors  are  introduced  during  requirements 
analysis,  specification  and  design  (Boehm  (76]).  Since  it 
may  cost  up  to  100  times  more  to  remove  errors  during  test¬ 
ing  than  shortly  after  introduction,  extended  correctness 
analysis  is  sorely  needed. 

To  achieve  such  savings,  techniques  must  be  used  to 
show  that  the  specification  correctly  implements  the 
requirements,  that  the  design  correctly  implements  the 
specification,  etc.  Thus,  correctness  analysis  spans  all 
activities. 


1.2.4  Management  Integration 


Management  is  an  important  activity  often  omitted  from 
life  cycle  models.  It  provides  control  over  other  activities 
and  provides  contingency  plans  for  unexpected  events.  To 
be  effective,  it  must  be  integrated  closely  with  all  other 
activities . 

Management  involves  both  insight  and  measurement. 

Insight  involves  seeing  what  people  are  doing  as  it  is 
being  done.  Measurements  are  needed  to  evaluate  the  work 
and  to  allow  management  to  learn  from  past  efforts. 

For  instance,  the  frequency  distribution  of  errors  over 
a  development  activity,  the  average  time  to  detection,  and 
correlation  of  error  types  to  methodologies  used,  could 
lead  to  improved  methods  of  software  development.  Measure¬ 
ments  also  allow  management  to  assess  progress  and  to  make 
adjustments  for  unplanned  situtations.' 


1.3  Relation  to  Acquisition  Management  Models 


The  life  cycle  model  presented  in  Section  1.2  supports 
the  definition  of  requirements  for  a  SEE.  More  specifically, 
it  supports  a  discussion  of  the  software  engineering  process 
contained  within  a  SEE.  This  model  does  not  match  directly 
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work. 

The  software  incremental  development  model  maps  to  the 
acquisition  model  activities  bracketed  between  system  con¬ 
cepts  and  system  integration  and  testing  as  follows: 


Acquisition 

Model 


System/Software  Requirements 
Analysis 

Software  Requirements  Analysis 

Preliminary  Design  &  Detailed 
Design 

Code,  Unit  Testirq,  and 
Integration  Tasting 

Software  rerfottnancs  Testing 
Formal  Reviews  (n.g. ,  PDR) 

iNo  equivalent) 


Incremental  Development 
_ Model _ 

Requirements  Analys 


Specification 

Design 

Implementation 
Corre-etness  Analysis 
Management 


The  incremental  development  model  activity  of  design 
is  divisible  into  system  level  design  and  program/data 
desian  (see  Section  2.3).  Therefore  it  matches  up  well 
wit.;  the  corresponding  activities  of  the  acquisition  mode  1  • 
The  correctness  analyse  activity  of  the  incremental  dove.)  - 
on r  mode  1  addr°ss*s  both  reviews  and  t ps •  .no  •<■.?**  iv :  t :  ns  . 
.  ."••  .t  : -'.c..  cc.  lii'i1.  .  I  n.u.-c  ration,  <-.:•••'  t ;i  for 
'  -i  ■:  h  e  !.  \  ■ ,  a  1  r e  v  .  e  +  —  i~  DR  ,  1 R .  e  ■  c  . 

■  -  •>«.  :  i  i  'j  :r, .  ■ . a  t  Jar  i  :* n  Re  »w  ;  ■ 1 CR  '  a s  r.  -  \  t :  : 1  a  • 


Page  1-14  i.3  Life  Cycle  Model;  Relation  to  Other  Models 

************************************************************** 


Smon 

5»««m  Jwiy 

Mtvumrw  Bwn> > 

Dm**  Ammm 

T  '-c»t  0**«qn  <**v*w 

-  Concur  1C  or  AkjO«l 

’Nmh  Com  <jMf*i*on  Awttit 
'ofm*  2M«i/tcnKiM 


r:gcre  1.3-1 : 


-cmt  -oaisrics  Commancers  I’-oocsea  _.:e  C/cie  Accuisition  Mocei 


2'om  -rjrt  oirrt  rc  >cv  -ocj.'ntnt  vjm  'Min«q«<r*tnt  M  Zomouttr  ^wourcei  *  5vit»r”l.  ’  9  Cctcctr  381 


.3  Eire  Cvcie  Model:  Relation  to  Other  Models 


it-****-***  *  *  it  it 


Page  1-13 


Review  i CDK ) ,  can  be  accommodated  within  the  incremental 
development  model  with  some  minor  adjustments.  Software- 
Specification  Review  (3S R,’  would  occur  at  the  end  of  tr.e 
iirst  system  specification.  PDR  would  occur  at  t;  e  and  of 
tr.e  first  design  activity  within  each  increment,  <*r»d  TER 
would  occur  at  the  end  of  the  design  activity  within.  r. 
increment.  with  incremental  development,  multiple  SDRs , 
one  in  each  increment,  will  be  needed.  Test  Readings  Review 
(TRR)  would  occur  when  the  system  testing  of  the  final 
increment  in  a  release  is  complete.  System  Requirements 
Review  (5RR)  ar.d  System  Design  Review  (SDR)  would  occur 
within  the  wider  perview  of  the  ECS  development  management. 


1.4  SEE  Requi  reman  ts  Derived  from  the  T..ifa  ?• 
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The  data  base  must  also  allow  programmers  to  keep 
intermediate  products  in  their  work  space,  providing 
for  iteration  within  increment. 

There  should  be  an  integrated  set  of  too i s  used  to 
define  the  products  in  the  baseline,  and  tool  sets 
to  aid  the  des igner/progranuner  wh'.  ie  working  coward 
the  baselined  products. 


cm  v  hedoiog  i  r  s  and  t  oo  J  ■> 


h,?-.  on  :i. 


-*«?  -  r  -in 


n  o  *-  "N  s >y  r>  * 


r  at  .  .  ■.  J* '■ 


:e  t  hodt 


Page  1-16  1.4  Life  C^cle  Model:  Derived  SEE  Requirements 


Measurements  of  each  activity  must  be  captured  for 
management. 

Tools  for  drawing  measurements  from  the  data  base 
and  for  analyzing  the  measurements  are  also  needed. 


z.  Metnoaoiogies  and  Tools 


The  following  subsections  explore  methodologies  and 
tools  which  support  the  software  engineering  process 
defined  by  the  incremental  development  life  cycle  model. 

The  subsections  also  summarize  the  requirements  they  levy 
on  the  SEE.  The  methodologies  chosen  reflect  today's 
state-of-the-art.  Certain  selected  alternate  methodologies 
might  be  chosen  without  major  changes  to  the  SEE  require¬ 
ments. 

For  each  life  cycle  activity,  the  activity  is  defined 
and  characterized  and  applicable  methodologies  and  tools  are 
then  discussed.  The  methodologies  and  tools  are  categorized 
as  follows: 

Formal  Recording  Aids  -  Those  methodologies  and 
tools  associated  with  the  capture  of  baseline 
products.  They  must  fit  together  from  one  activity 
to  another  and  promote  traceability,  which  is  the 
relation  of  products  (or  their  parts)  in  one  activity 
to  the  products  (or  their  parts)  in  adjacent 
activities  in  the  life  cycle  model. 

Creativity  Aids  -  Methodologies  or  tools  augmenting 
the  creative,  intellectual  processes. 

A  minimum  set  of  methodologies  and  tools  for  formal 
recording  is  required.  The  creative  aids,  on  the  other  hand, 
can  be  anything  that  helps  an  analyst,  designer,  programmer, 
or  tester,  create  a  product.  The  product  is  then  formally 
recorded  for  baseline  control  under  configuration  management. 

The  life  cycle  model  described  in  Section  1.2  provides 
a  framework  for  defining  appropriate  methodologies  and 
tools.  However,  it  must  be  placed  in  the  context  o"  the 
weapon  system  acquisition  life  cycle  for  an  understanding 
of  the  role  of  the  front-end  software  engineering  methodolo¬ 
gies.  Figure  2-1  shows  a  progression  of  weapon  system 
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NOTE: 

1 .  IDEAL  POINT  OF  FIRST  INVOLVEMENT  BY  SOFTWARE 
DEVELOPMENT  (REQUIREMENTS  ANALYSIS). 

2.  USUAL  STARTING  POINT  FOR  SOFTWARE  DEVELOPMENT 
(SPECIFICATION). 


Figure  2  1 :  The  Starting  Point  of  the  Software  Engineering  Process 
within  a  Weapon  System  Life  Cycle 
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design  and  specification^-  documents  at  some  point  after 
the  definition  of  the  weapon  system  concept.  In  an  ideal 
world,  the  ECS  software  development  agent  would  first 
enter  the  process  at  the  ECS  Specification  and  Design 
(Type  A  specification}  to  ensure  feasibility  of  the  approach. 
The  formal  starting  point  for  software  development  would 
be  the  Software  Subsystem  Specification  (Type's  specif ica- 
c ion )  . 


The  requirements  analysis  activity,  which  is  the  first 
activity  in  the  incremental  development  model,  of  necessity 
will  involve  the  software  development  agent  in  system  level 
questions  such  as  hardware/software  trade-off  issues. 
Hopefully,  such  involvement  will  lead  to  a  set  of  system 
level  requirements  which  will  allow  efficient  design  and 
implementation  of  quality  software. 


2.1  Requirements  Analysis 


Requirements  analysis  involves  looking  at  the  require¬ 
ments  within  the  ECS  specification  and  design  level  before 
developing  the  software  system  specification. 

In  most  cases  today,  the  progression  of  Figure  2-1  is 
just  an  ideal.  More  likely,  the  software  development  agent 
is  brought  in  after  the  equivalent  of  the  ECS  design  is 
complete.  Furthermore,  the  requirements  for  the  software, 
as  represented  by  the  ECS  specification  and  design  documents 
in  the  ideal  case,  are  not  well  defined.  They  may  be 
contained  in  many  sources  including  documents,  memos,  and 
the  minds  of  the  ECS  designers.  Therefore,  requirements 
analysis  also  must  address  the  capture  and  interpretation 
of  requirements  from  these  sources. 

Although  requirements  analysis  begins  the  software 
engineering  process,  this  activity  does  not  necessarily  end 
with  the  start  of  software  specification.  Requirements 
analysis  continues  over  the  software  life  cycle  because  of 


^  Specification  was  defined  in  Section  1  as  a  rigorous 
external  description  of  a  system  without  concern  for  its 
internal  workings.  This  type  of  description  is  sometimes 


referred  to  a  "black  box." 
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Characteristics 


Requirements  are  binding  conditions.  In  Figure  2-1, 
requirements  on  imp.1  ementors  at  one  level  in  the  hierarchy 
are  any  binding  conditions  imposed  at  the  higher  levels. 

These  requirements  can  take  many  forms.  For  the  following 
discussion  of  requirements  analysis,  the  different  forms  ^C 
requirements  will  be  classified  as  follows: 

Context  -  Bounds  on  alternatives  for  the  software 
system  design  implied  by  the  system  mission  or 
environment. 

Description  -  Characterization  of  what  the  required 
system  is  to  do  without  concern  for  how  it  will  work. 

Constraints  -  Any  conditions  which  must  be  met  in 
designing  or  implementing  the  required  system  or 
any  quantitative  performance  measures  to  oe  met  by 
the  operational  system. 

Evaluation  Criteria  -  Rules  to  be  used  in  judging 
the  quality  of  the  completed  system. 

Requirements  analysis  involves  two  sub-activities: 
requirements  interpretation  and  feasibility  assessment. 
Interpretation  concerns  identifying  and  defining  software 
requirements  so  that  correct  specifications  are  possible. 
Feasibility  assessment  concerns  determining  the  reasonable¬ 
ness  of  implementina  a  svstem  that  can  satisfv  the  requirements 
within  schedule  and  cost.  The  identification  of  risk  in 
this  regard  may  lead  to  a  redefinition  of  the  requirements 
with  the  ECS  designers. 
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categorized  terms.  Examples^-  of  techniques  based  on  semantic 
models  are  Structured  Analysis  and  Design  Technique  (SADT) 
(Ross  and  Shoman  [77])  and  Problem  Statement  Language  (PSL) 
(Teichroew  and  Hershey  [77]).  The  underlying  semantic 
models  of  SADT  and  PSL  differ  in  categories  and  relations 
chosen. 

There  are  several  benefits  to  expressing  the  require¬ 
ments  in  the  form  of  a  semantic  model: 

Definition  in  Context  -  Key  terms  of  the  require¬ 
ments,  defined  in  the  context  of  other  problem- 
related  terras,  reduces  ambiguity  and  increases 
understanding  between  the  weapon  system  engineers 
and  the  software  engineers.  Thus,  semantics  infor¬ 
mation  can  be  thought  of  as  a  sophisticated  data 
dictionary. 

Specification  Mapping  -  If  the  semantic  model 
categories  and  relations  were  properly  chosen,  the 
semantic  information  will  suggest  a  natural  mapping 
for  the  system  specification.  This  specification 
precisely  expresses  the  description  requirement. 

Consistency/Completeness  Analysis  -  The  semantic 
information  depicting  the  context  and  description 
requirements  can  be  analyzed  for  both  consistency 
and  completeness.  This  analysis  is  based  on  the 
relations  found  in  the  semantic  model. 

Traceability  -  The  semantic  information  can 
establish  traceability  between  the  requirements 
source  and  the  specification.  It  does  this  by 
including  references  in  the  definitions  of  terms. 
Later,  these  references  can  be  extended  to  related 
baselined  products. 

Design  Aid  -  Naming  consistency  can  be  maintained, 
and  traceability  can  be  extended,  by  definition  of 


4  Throughout  Part  I  of  this  document,  existing  methodologies 
and  too  Is  will  be  cited  to  illustrate  the  feasibility  of  the 
concepts  presented.  They  are  cited  as  examples  only.  There 
is  no  implication  intended  that  these  be  t3xen  as  require¬ 
ments  on  a  Navy  SEE. 
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a  trial  das  ion  first.  Such  a  design  demons  traces  tie  fe-si- 
co  iity  the  context,  decor  *pt  ion ,  and  cons  a  a  m  t  r-qr.  i->:- 
. tents  (but  .a  ty  overlook  other  cons  3era  ;ons  ,  A  •  • 

s imu l.it  i  or  tf  a  trial  des iar.  can  be  used  to  show  how  ■■ 
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Resource  estimation  tachniq-.,  as  are  ust-fui.  They  .  *n 
assess  the  feasibility  of  ’  npiemente ?. i on  constraints  ;uc.n 
ns  a  milestone  of  initial  operation*  inability.  iney  can 
also  assess  the  impact  at  evaluation  cri'.euia.  Applying 
these  '.cchn.aier.  to  the  trial  design  \  allow.!  ng  for  a  •  t  r  a 
work  to  meet  tne  evaluation  criteria!,  one  can  <*s,-  :«are 
teasonaole  resource  and  -  •-•hedu  1  <■?  expectations.  These,  m 
burr.,  can  i  e  compared  tc  the  i.nplemer,-:  at :  .:-n  com  -amts. 

Ri-ik  areas  cur  he  identified  w_th  modeling  and  resource 
estimation  techniques.  The  requirements  might  then  be 
changed  to  eliminate  infeasible  or  conflicting  requirements, 
or  to  reduce  the  risk  linked  to  certain  requirements. 


2.1.2  Methodologies 


Several  methodologies  can  be  used  during  requirements 
interpretation  and  feasibility  assessment. 

Semantics  Information  Capture  -  Supporting 
i nterpretation,  the  capture  of  requirements  in  the 
form  of  a  semantic  model  involves  identifying  key 
Terms,  categorizing  the  terms,  defining  the  .arts, 
and  identifying  the  relations  between  the  terms. 
The  capture  of  semantics  information  creates  a 
.  ormal  recording  of  the  semantic  model  of  the 
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requirements,  which  becomes  part  of  the  baseline. 

An  example  of  a  comprehensive  methodology  for 
semantics  information  capture  is  suggested  in 
Wilson  [79] .  Assuming  the  semantics  information  is 
machine-encoded,  it  might  be  expressed  in  a  formal 
language  such  as  Problem  Statement  Language  (PSL). 

Semantic  Analysis  -  Once  the  requirements  are 
expressed  in  the  context  of  a  semantic  model,  the 
model  relations  can  be  used  for  a  systematic  analy¬ 
sis  of  the  completeness  and  consistency  of  the 
requirements.  This  is  achieved  by  asking  questions 
which  are  answered  with  the  aid  of  the  relations, 
such  as  "Are  there  any  other  processes  which  should 
be  related  to  Process  A  by  the  'predecessor  of* 
relation?" 

Traceability  may  be  established  through  reference 
relations  between  requirements  and  specification, 
design  and  code,  etc.  The  relational  analysis  can  be 
used  to  assess  the  impact  of  requirements  changes  on 
the  baselined  products. 

The  semantic  analysis  methodology  also  aids  creation 
by  identifying  areas  of  requirements  incompleteness 
or  inconsistency. 

Feasibility  Analysis  -  Evaluating  the  feasibility 
of  requirements  is  a  significant  part  of  require¬ 
ments  analysis.  Feasibility  should  be  viewed  from 
the  perspectives  of  design,  performance  and  cost. 

Design  feasibility  involves  finding  at  least  one 
design  that  satisfies  the  requirements.  Any 
approach  from  trial  design  to  prototyping  is  appro¬ 
priate.  Performance  feasibility  is  a  special  case 
of  design  feasibility  analysis.  Once  a  trial  design 
is  established,  modeling  is  an  effective  technique 
for  analyzing  performance.  Cost  feasibility  involves 
estimating  costs  based  on  the  trial  design.  Cost 
analysis  must  consider  the  three  key  elements:  the 
development  phase,  the  operations  phase,  and  the 
phase  for  continuing  adaptation. 

The  software  development  agent  may  have  to  go  through 
several  iterations  with  the  weapon  system  or  ECS  manager. 
Together  tr.ey  can  resolve, problems  discovered  during 
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requirements  analysis,  such  as  infeasible,  inconsistent,  or 
over -cons train log  requirements.  The  methodologies  sunwa- 
.  .aod  aiovc  may  be  used  oef ore  .*n  acceptable  set  of  require- 
tents  for  the  software  sy: tern  is  reached. 


2.1.3  Supporting  Tools 


Several  tools  are  effective  in  supporting  the 
methodologies  described  above. 

Semantics  Language  Processor  -  A  language  processor 
could  perform  syntax  checking  and  recording  of 
semantics  information  entered  via  a  language  such 
as  PSL.  The  results  would  be  available  for  later 
analysis  or  retrieval.  The  information  would 
resemble  a  data  dictionary  augmented  by  relations. 

Information  Storage  and  Retrieval  -  This  tool 
would  store  and  retrieve  the  semantic  information. 

It  might  be  based  on  a  data  base  management  system 
(DBMS)  using  relational  techniques.  An  example  of 
such  a  tool  used  in  this  application  is  IBM’s 
Query-by-Exaraple  (QBE)  (Perriens  [79]). 

Semantics  Information  Analyzer  -  This  tool  would 
use  the  relational  nature  o£  the  semantics  informa¬ 
tion  to  perform  consistency  and  completeness  checks. 
Problem  Statement  Analyzer  (PSA)  (Teichroew  [77] )  is 
an  example  of  a  tool  used  to  analyze  data  captured 
through  the  use  of  PSL. 

Report  Generator  -  General  report  generators 
would  help  create  requirements  analysis  reports. 
Examples  of  reports  are  (Orzech  [79]): 

-  Formatted  problem  statement  report,  which  gives 
the  original  relationships  in  a  well-structured 
format • 
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Data/activity  interaction,  which  shows  interaction 
between  data  objects  and  activities,  and 

Picture  report,  which  diagrams  the  direct 
relationships  of  an  object. 

Modeling  Tool  -  This  tool  would  provide  queuing 
theory  aids  tailored  to  descriptions  of  computer 
systems.  The  tool  assists  in  developing  performance 
analysis  models.  Performance  Oriented  Design 
{ BGS  [78])  is  an  example  of  such  a  queuing  tool. 

Other  modeling  tools  besides  queuing  would  also  be 
appropriate. 

Resource  Estimator  -  An  estimation  model  can  help 
assess  cost  feasibility.  The  model  would  use  char¬ 
acteristics  of  the  software  system  and  the  develop¬ 
ment  approach  to  predict  required  manpower,  sched¬ 
ule,  and  computer  resources. 

Prototyping  -  Tools  for  developing  prototypes  of 
software  systems  would  be  useful.  They  might 
consist  of  a  high-level  language  and  an  interpreter. 


2.1.4  Requirements  on  the  SEE 


The  requirements  on  the  SEE  data  base,  derived  from 
requirements  analysis,  are: 

Baselined  Products  -  The  semantics  information  is 
the  only  data  associated  with  requirements  analysis 
that  should  be  baselined.  It  should  be  under 
configuration  control  and  subject  to  change  only  as 
requirements  changes  are  approved. 

Non-Basel ined  Data  -  Any  information  associated 
with  modeling,  simulation,  prototyping,  or  semantic 
analysis  should  be  saved  temporarily.  It  can  be 
used  later  in  requirements  analysis  iteration  or 
other  activities. 

Measurement  Data  -  Several  measurements  of  the 
requirements  analysis  activity  and  its  outputs 
should  be  captured: 
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-  Number  of  inconsistencies  or  omissions  found. 

The  support  system  must  provide  a  framework  for  the 
types  of  tools  summarized  in  Section  2.1.3.  Given  the  rela¬ 
tional  nature  of  the  semantics  information,  another  require¬ 
ment  might  be  that  the  DBMS  support  relational  operations. 

2.2  Specification 


The  specification  activity  should  transform  the  descrip¬ 
tive  requirements  into  a  precise  statement  of  the  software 
system  external  behavior.  Two  key  information  sources  are 
used  in  this  transformation:  (1)  semantics  information 
captured  during  the  requirements  analysis,  and  (2)  the  ref¬ 
erenced  requirements  information  from  which  it  was  derived. 
The  resulting  specification,  along  with  the  constraints 
and  evaluation  criteria  requirements,  provides  the  basis 
for  design,  implementation,  and  correctness  analysis.  In 
most  cases  the  constraint  requirements  should  be  included 
as  part  of  the  specification  (perhaps  as  an  appendix). 

Thus,  the  specification  will  contain  all  that  must  be 
known  to  implement  the  software  system.  The  specification 
also  provides  the  basis  for  judging  the  correctness  of  the 
implemented  system. 


2.2.1  Characteristics 


Specification  development  consists  of  two  distinct 
acts.  The  first  is  to  collect  information  that  the 
specification  will  contain,  this  is  a  creat: ve  process. 

The  second  is  the  act  of  record  ing  this  inf ocrrat  ion. 
Although  these  actions  may  be  carried  out  simultaneously • 
normal!'/  :  an  iterative  far;  hi  on,  tney  she  u J  ■  beside .  “ 
•>oua  rate!’,  since  each  suaaeats  Its  own  me  t  n  cdo.'.c<:  •  ss  snd 
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Developing  the  system  specification  must  be  done  in 
such  a  way  that  the  specification  can  always  be  shown  as 
complete  and  consistent. 

The  semantics  information  produced  during  requirements 
analysis  can  provide  traceability  between  the  system  require¬ 
ments  and  specification.  This  link  can  show  subjectively 
the  correctness  of  the  specification.  It  is  helpful  in 
providing  insight  into  how  the  specification  must  be  updated 
as  changes  to  the  requirements  are  made. 

If  feasibility  analyses  were  not  conducted  during 
requirements  analysis,  they  should  be  conducted  during 
specification  development.  Again,  this  analysis  consists 
of  constructing  a  model  (or  simulation  of  the  system)  and 
performing  analyses  to  see  if  the  desired  timing  and  accuracy 
criteria  can  be  met. 


2.2.2  Methodologies 


The  specification  information  must  be  recorded  in  some 
suitable  form.  As  a  minimum,  the  specification  should 
describe : 


Interactions  -  the  interactions  of  the  software 
system  and  Its  outside  environment  (i.e.,  descrip¬ 
tions  of  I/O  device  interfaces,  sensor  interfaces, 
etc. ) ; 

Modes  -  externally  visible  modes  of  operation 
(e.g.,  "initialize"  or  "auto  pilot");  and 

Functions  -  externally  visible  functions  (e.g., 
mappings  of  inputs  to  outputs). 

Furthermore,  any  methodology  for  recording  the  system 
specification  should  produce  a  document  which  is: 

Minimal  -  The  purpose  of  a  specification  is  to 
define  what  the  system  must  do.  A  minimal  speci¬ 
fication  will  describe  only  this;  and  it  will  net 
imply  any  special  use  of  the  system.  Such  specifi¬ 
cations  are  said  to  be  olack  box  because  they 
describe  only  the  externally  ooservable  behavior 
of  the  system.  A  minimal  specification  has  the 
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Understandable  -  Since  the  specification  wi_i  oe 
use3” heavily  as  a  reference  tool  by  system  imple¬ 
mentors  and  mai.ntainers,  it  should  be  clear  and 
concise.  The  information  must  be  well  organized 
so  that  answers  to  particular  questions  are  easy 
to  find.  The  text  should  De  free  of  jargon. 

Accurate  and  Precise  -  The  specification  must  be 
as  complete  and  consistent  as  possible.  The 
specification  should  use  as  much  formal  notation  as 
possible.  Such  notation  is  needed  for  a  formal 
correctness  analysis.  It  also  makes  automated 
analysis  of  the  specification  information  easier. 

Easily  Modified  -  The  evolving  nature  of  require¬ 
ments  suggests  that  the  specification  information 
be  easy  to  update  and  change.  This  can  be  done  by 
organizing  the  information  so  that  different  aspects 
of  the  specification  are  described  separately  and 
independently.  This  approach  minimizes  the  impact 
of  a  single  change  to  the  specification. 

The  creative  aspect  of  specification  development  is 
the  synthesis  of  the  proper  information  for  the  specifica¬ 
tion.  This  necessarily  involves: 

Completeness  Analysis  -  This  is  done  by  trying 
out  a  design  of  the  system.  Completeness  analysis 
generates  questions  which  can  help  identify 
information  absent  from  the  requirements.  In  most 
cases,  this  activity  will  be  done  during  require¬ 
ments  analysis. 

Correctness  Demonstration  -  The  specification 
must  be  shewn  as  consistent  with  the  requirements. 
Since  the  requirements  may  not  be  stated  in  a  formal 
manner,  a  rigorous  proof  of  their  consistency  may 
not  oe  possible.  The  correctness  demonstration  is 
then  produced  through  a  subjective,  informal  analy¬ 
sis  cased  on  the  semantics  information  from  require¬ 
ments  analysis  ;  ?er rent i no  and  r.ills  [77’.;. 
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Consistency  Analysis  -  Any  methodology  for  cer- 
tomur.g  this  analysis  depends  on  the  form  of  tne 
specification  information.  It  a  formal  specifica¬ 
tion  language  is  used,  certain  kinds  of  problems 
may  be  detected  by  analyzing  this  notation.  In 
other  cases,  the  consistency  of  the  specification 
information  must  be  judged  on  a  less  precise  oasis. 


A  good 
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xampie  of  the  state-cf-tne-art  in  specification 
:es  is  that  advocated  bv  Parras  and  Hem. ncer 
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flight  or 

tabular  notation  which  lends  itself  to  completeness 
consistency  analyses. 
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2.2,3  Supporting  Tools 


The  following  tools  help  to  develop  the  specification. 

Language  Analyzers  -  These  can  check  for  errors  in 
any  formal  notation  within  the  specification 
information.  These  analyzers  are  tailored  to  the 
specification  language  or  notation  used.  They 
receive,  as  input,  the  specif ication  (or  some 
portion  thereof)  and  issue  diagnostics  concerning 
syntax  errors. 

Cons  is tency /Completeness  Analyzer  -  These  analyze 
information  entered  via  formal  language  and  detect 
inconsistencies  or  omissions  in  the  specification. 
For  example,  tables  might  specify  some  outcome  as 
a  function  of  various  factors.  The  tables  can  be 
checked  to  ensure  that  an  outcome  is  given  for  every 
event,  and  that  no  event  corresponds  to  two  mutually 
exclusive  outcomes. 

Modeling  Tools  -  These  may  be  needed  if  no 

pe r f ormance  Feasibility  study  was  conducted  during 

requirements  analysis. 

Report  Generators  -  These  are  needed  to  produce  a 
finished  document  from  the  speci f icat ion  information 
stored  in  the  data  case. 


Speci f icat ion 
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2.2.4  Requirements  on  the  SEE 


The  requirements  cn  the  SEE  data  base,  derived  from 
the  specification  activity,  are: 

3aselined  Products  -  The  specification  information 
is  oase  1  lined .  Any  modeling  information  produced 
might  be  baselined  if  it  is  crucial  to  the  life 
cycle  support  of  the  software. 

Non-Baselined  Data  -  This  material  includes 
partial  specifications  under  development,  alternate 
specifications,  and  diagnostic  information  produced 
by  specification  analysis  tools. 

Measurements  -  Examples  wt  useful  measurements 
are!  effort  and  resource  data  concerning  the 
development  of  the  specification,  size  data,  number 
of  errors  and  changes  made,  and  subjective  measures 
of  the  quality  and  completeness  of  the  specification. 


2.3  Design 


Design  involves  creating  an  abstraction  of  a  system. 

When  implemented  according  to  this  design,  the  system  will 
meet  the  software  system  specification,  the  constraint 
requirements,  and  the  evaluation  criteria.  A  design  formally 
describes  the  system.  Decomposition  and  abstraction  are 
the  key  means  of  dealing  with  the  complexities  of  a  system 
during  its  design.  Decomposition  involves  dividing  the 
system  into  pieces  (modules,  programs  and  data  structures), 
which  can  be  related  in  some  hierarchic  fashion.  These 
pieces  can  be  handled  independently  during  further  decompo¬ 
sition  of  the  design.  Abstraction  is  used  to  suppress  ail 
but  those  details  needed  to  understand  the  design  at  any 
level . 

The  concept  of  hierarchy  is  important  for  traceability 
and  correctness  of  the  design.  The  correctness  techniques 
developed  tnus  far  rely  on  a  hierarchy  in  the  design, 
furthermore,  a  complex  design  can  be  better  understood 
through  abstraction  plus  a  hierarchy  showing  the  relations 
among  the  pieces. 
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A  precise  specification  of  the  system  is  vital  to  the 
design  process.  Design  can  begin  without  complete  specifi¬ 
cations,  but  the  missing  parts  must  be  clearly  acknowledged 
as  unknown.  The  specification  must  be  complete  by  the  time 
design  is  complete. 
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Design  consists  of  creation  and  recording.  Creation 
is  a  highly  intellectual  process.  Several  alternative 
designs  may  be  created  and  assessed  before  a  design  approach 
is  chosen.  The  creation  activity  draws  on  the  skill  and 
experience  of  the  designers.  It  may  require  modeling  and 
trade-off  studies  to  reach  a  roasonaoie  solution.  Once  a 
design  approach  is  chosen,  the  formal  recording  act  depends 
on  the  means  of  decomposition  and  choice  of  abstractions, 
formal  recording  is  enhanced  by  techniques  which  foster 
clarity,  understanding,  correctness  analysis,  and  ease  of 
change  . 

Another  view  of  design  highlights  the  difference 
between  system  design  (design-in-the-large )  and  data  and 
program  design  ( des ign-in-the-small ) .  System  design 
involves  breaking  down  (decomposing)  the  software  system 
■ nto  hierarchically-related  modules.  ~ach  module,  in  turn, 
:ms  a  module  specification.  Design- in-the-small  addresses 
the  design  of  individual  modules.  It  defines  abstract  data 
structures  and  programs  composing  the  module.  These  pro¬ 
grams,  in  turn,  may  invoke  functions  of  other  modules.  One 
way  program  designs  may  be  described  is  through  a  Program 
Design  Language  (PDLM. 

The  method  of  decomposing  the  software  system  into  mod¬ 
ules  is  central  to  software  system  design.  If  modularity 
is  not  viewed  properly,  the  software  will  not  be  easy  to 
change . 

Two  related  concepts  that  are  important  for  creating 
good  modules  are  information-hiding  and  data-mtensive 
design.  Information-hiding  isolates  design  decisions  likely 
to  change  in  the  future.  It  also  provides  an  interface 


*  PDL  is  also  used  as  an  acronym  for  "process  design  language" 
or  "procedure  design  language." 
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between  the  nodule  and  the  rest  of  the  product  that  regains 
valid  for  all  versions.  Module  specifications  designed  wi  zr. 
i  nformat ion-hiding  would  reveal  functional  lapabilif : 
net.  the  design  decisions  underlying  the  implementation. 

Many  people  view  data  rather  than  function  as  the  major 
factor  influencing  a  design.  The  design  decisions  deal  with 
data — its  structure,  the  means  of  access  to  it,  and  the  fac¬ 
tors  involved  in  altering  it.  Module  design,  using  the  con¬ 
cept  of  data-i.nter.s ive  design,  would  begin  with  the  creation 
of  abstract  data  structures,  followed  by  the  design  of  the 
programs  acting  on  these  data  structures. 

In  summary,  the  recorded  design  consists  of  the 
following  elements: 

Module  hierarchy  representing  the  system  decomposi¬ 
tion, 

-  Module  specifications  to  reveal  the  external 
descriptions  of  the  module,  and 

-  Module  designs  consisting  of  program  designs 
and  abstract  data  definitions. 

The  design  of  the  system  must  support  incremental 
development.  The  design's  decomposition  structure  should 
allow  the  system  to  be  built  incrementally.  Such  a  structure 
may  make  the  implementation  easier  and  will  almost  certainly 
make  continuing  adaptation  easier.  It  also  allows  the 
designer  to  focus  on  the  more  difficult  parts  of  the  design 
in  the  beginning,  thereby  improving  the  chances  for  the 
best  solutions. 


2.3.2  Methodologies 


Three  groups  of  design  methodologies  are  identified: 
formal  recording  of  system  design,  formal  recording  of  data 
and  program  design,  and  creative  aids. 

"here  are  several  techniques  for  record. r-.g  the  systt-it 
cesign. 

Inf oraat ion- Hiding  -  This  technique  involves 
isolating  information  within  modules.  The  -noduie 
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limits  are  defined  by  the  information  (design 
decisions,  data  definitions,  etc.)  to  be  isolated. 
Design  is  based  on  the  expected  changes  to  the  infor¬ 
mation,  thus  localizing  the  effect  of  future  changes 
( Parnas  [79] ) . 

Module  Specification  -  This  technique  allows 
others  to  determine  the  intent  of  a  complete  module 
by  reading  the  module  specification. 

Uses  Hierarchy  -  This  technique  explains  which 
programs  depend  on  the  correct  implementation  of  a 
given  module  to  produce  correct  results  (Parnas  [79]) 

The  techniques  for  the  formal  recording  of  data  design 
and  program  design  are: 

Program  Design  Language  (PPL)  -  PDL  is  a  useful 
technique  for  formally  recording  the  program  design. 
It  is  sufficiently  low-level  to  support  direct  coding 
and  is  flexible  enough  to  leave  some  questions  unan¬ 
swered  while  the  designer  proceeds  with  the  design. 

Stepwise  Refinement  -  This  technique  goes  hand  in 
hand  with  PDL.  with  stepwise  refinement,  specifi¬ 
cations  for  the  lower  level  code  become  part  of  the 
documentation  of  the  procedure.  This  makes  the 
intent  of  the  code  much  clearer. 

Abstraction  of  Data  Types  -  With  abstraction,  the 
designer  can  develop  details  where  they  are  needed 
(Guttag  and  Liskov  [77]).  This  permits  information¬ 
hiding  as  well  as  a  more  independent  implementation 
of  the  system. 

Many  creative  techniques  exist  for  design.  A  designer 
chooses  techniques  based  on  their  individual  approach  to 
creativity.  Some  prefer  graphic  techniques  while  others  do 
not.  The  choice  of  creative  techniques  should  be  left  to 
the  individual,  whereas  the  techniques  for  formal  recording 
must  be  standard.  Described  below  are  some  representative 
creative  aids: 

Data  Flow  Analysis  -  Module  decomposition  and 
function  allocation  are  based  upon  the  data  flows 
required  by  the  system.  An  example  is  Structured 
Design  (Stevens  [74]). 
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Data  Structure  Tr  ar.s  f  orma  r  i  an  -  Trans  forma  cion 
is  a  design  technique  in  which  n e  structure  of  the 
input  and  output  data  determines  the  structure  of 
the  program  {Jackson  [77]). 

Graphic  Decompcs  it  ion  Techniques  -  Graphs  showing 
hierarchic  relations  depict  the  decompos:  tier.  at 
many  levels.  An  example  is  Structured  Analysis  and 
Design  Technique  (SADT). 

Graphic  Control  Descriptions  -  Other  ways  of  show¬ 
ing  the  control  £  1 ows  in  the  program  are  Petri  Nets 

and  Warnier-Orr  diagrams. 

2.3.3  Supporting  Tools 


Figure  2. 3. 3-1  lists  the  design  methodologies  outlined 
in  Section  2.3.2  and  identifies  tools  that  might  support 
some  of  the  methodologies.  The  tools  are  briefly  described 
below. 

Design/Specification  Language  Processor  -  These 
check  syntax  and  connections.  Input  is  the  system 
design  and  the  module  specifications  written  in  some 
standard  syntax.  Output  is  a  list  of  inconsistencies 
or  syntax  errors. 

PPL  Syntax  Analyzer  -  These  detect  mismatched 
interface  items  and  force  the  designers  to  maintain  a 
consistent  syntax  for  the  design.  Input  is  a  design 
written  in  a  POL,  and  output  is  a  list  of  syntax 
errors  and  inconsistencies  in  data  usage. 

PPL  Interpreter  -  These  would  allow  a  design  to  be 
executed  before  it  is  actually  coded.  The  interpret¬ 
er's  input  is  a  design  written  in  a  PDL  with  program 
input  data.  Its  output  shows  the  result  of  applying 
the  input  data  to  the  design. 

Graphics  Package  -  These  would  support  the  creative 
phase  of  design.  Various  designs  could  be  displayed 
graphically  to  aid  the  designer  in  making  a  choice. 
Input  might  be  module  descriptions,  hierarchy  rela¬ 
tions,  or  data-use  relations.  Output  might  be  graphic 
representations  of  this  information. 
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Figure  2. 3. 3-1:  Methodologies  and  Tools  of  Design 
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execution  and  timing  statistics.  These  statistics 

may  be  used  to  determine  if  the  design  could  meet  tne 
performance  requirements. 

Report  Generators  -  These  transform  stored  design 
into  documents  and  reports.  Thus  the  baselined  design 
will  be  stored  in  machine-readable  form,  permitting 
required  documents  to  be  produced  easily. 


2.3.4  Requirements  on  the  SEE 


As  with  the  other  activities  of  development,  the  data 
base  must  contain  information  on  the  design. 

Baselined  Products  -  Throughout  the  life  of  the 
system,  the  most  recently  approved  form  of  the  design 
must  be  stored  in  the  data  base.  The  system  design 
may  be  entered  before  the  design  of  various  subsystems 
or  modules. 

Non-Baselined  Data  -  This  includes  preliminary 
designs  as  well  as  graphic  displays  used  during  the 
creative  process.  Graphic  displays  may  include  tree 
structures,  block  diagrams,  and  other  material  created 
by  design  tools.  The  data  base  must  provide  for 
maintaining  the  temporary  designs  developed  before  one 
is  actually  chosen  and  baselined. 

Measurements  -  These  might  include  module  intercon¬ 
nection  measurements,  such  as  data  bindings  (Basili 
and  Turner  [75]).  These  might  also  include  lower 
design  measurements,  such  as  cyclomatic  complexity 
(McCabe  [76]),  and  operators  and  operands  (Halstead 
[77]).  Many  of  these  measurements  are  normally  taken 
on  the  completed  code,  but  with  good,  low-level  PDL , 
they  can  be  taken  '.or  approximated)  during  design. 

Archival  Data  -  Archived  data  snouid  capture  the 
motivation  behind  the  choice  of  design.  The  archived 
data  should  also  include  past  designs  evolved  from 
use  or  rejected  during  development  a  1  o:sc  with  the 
i ea.'Ons  for  the  rejection. 
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2.4  Implementation 


The  implementation  phase  should  create  a  system  which 
implements  the  design  correctly  and  meets  the  resource, 
accuracy,  and  performance  constraints  in  the  specification 
Implementation  translates  design  into  the  language  of  the 
target  computer,  the  data  base,  and  other  products  needed 
to  create  the  operational  system. 


2.4.1  Characteristics 


Implementation  should  produce  an  effective,  understand¬ 
able  realization  of  the  design.  Clear,  readable  source 
text  is  required  for  ease  of  maintenance. 

The  following  are  the  key  aspects  of  implementation: 

Code  Generation  -  This  translates  the  design  to  the 
machine  language  of  the  target  computer.  It  varies 
in  difficulty  based  on  the  level  of  the  design  and 
the  level  of  the  target  language.  Code  generation 
begins  with  the  expansion  of  the  detailed  design  into 
the  appropriate  programming  language.  As  with  system 
design,  correctness  arguments  make  a  correct  imple¬ 
mentation  easier  to  produce. 

Assembly/Compilation  -  The  generated  code  must  be 
comp ilea  or  assembled.  This  process  checks  the  code 
for  certain  errors  and  produces  its  relocatable  binary 
translation  (or  object  module). 

Debugging  -  It  is  usually  helpful  to  do  as  much 
debugging  as  possible  on  the  host  computer  rather 
than  on  the  target  computer.  This  is  especially  true 
of  unit  testing.  The  testing  might  be  done  on  the 
development  host  using  a  simulator  of  the  target 
machine.  In  some  cases,  a  host-to-target  connection 
is  used  for  the  test.  Another  option  is  to  translate 
the  source  code  for  direct  execution  on  the  host  com¬ 
puter. 

System  Integration  -  Units  from  the  compilation 
activity  are  tagged  with  information  on  increment, 
version  and  revision  number,  and  are  scored  in  the 
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across  units.  'These  concepts  of  integrating  i :  : 
those  of  the  Ada  development  process.) 

System  Generation  or  SYSGEN  -  This  process  involves 
creating  an  operational  system  for  a  target  computer. 
It  uses  integrated  components  plus  instructions  ti¬ 
the  operating  system,  the  linker 'loader,  the  cats 
base  management  system,  and  special  SY3CEN  tools. 

The  output  from,  these  instructions  are  load  modules, 
a  data  base  or  files,  and  the  structures  that  define 
the  system  configuration.  These  will  then  be  recorded 
on  a  transportable  physical  medium  such  as  magnetic 
tape.  They  will  be  in  a  form  suitable  for  loading 
the  system  into  the  target  ECS. 

Optimization  -  The  system,  or  parts  of  it,  may  need 
to  be  "fine  tuned"  to  meet  performance  specifications. 
The  performance  criteria  will  vary  according  to  the 
system  and  can  include  external  criteria  such  as 
response  times  for  transactions,  or  internal  criteria 
such  as  memory  limitations,  "thrashing"  by  the  virtual 
operating  system,  or  priority  structures. 

The  programming  environment  must  be  able  to  support  Ada 
as  well  as  other  Navy  standard  languages  or  authorized  non¬ 
standard  languages.  Supporting  Ada  requires:  a  compiler, 
a  run-time  environment  capable  of  the  tasking  and  exception¬ 
handling  features  of  Ada,  and  a  mechanism  to  handle  the 
separate  compilation  facilities  of  the  language. 


2.4.2  Methodologies 


In  many  ways,  translating  a  design  into  a  system  for 
the  target  computer  is  a  straightforward  (indeed,  almost 
mechanical)  task.  Thus  few  methodologies  and  many  software 
tools  are  available  for  this  aspect  of  software  development. 


Structured  Programming 
structures  are  used  for  al 
are  also  one-m,  one-out. 


One-in,  one-out  contrci 
programs;  thus,  programs 
Programs  are  viewed  as 
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function  composition  of  the  one-in,  one-out  control 
structures  providing  a  rigorous  basis  for  correct¬ 
ness  analysis. 

Top-Down  Implementation  -  System  components  can  be 
des igned ,  implemented  and  integrated  in  such  an 
order  that,  tnroughout  the  Integra- ion  process,  an 
operable  subset  of  the  system  will  exist;  this  is 
called  top-down  implementation.  As  implementation 
proceeds,  each  new  program  is  integrated  into  the 
operable  subset.  Top-down  implementation  is  like 
incremental  development  in-the-smali .  In  fact,  it  is 
performed  within  development  increments. 

Programming  Teams  -  These  have  proved  to  be  an 
effective  means  of  increasing  productivity  and  quality 
(Baker  [75]  and  Weinberg  [71]).  On  large  projects, 
the  system  design  must  be  decomposed.  Then  components 
can  be  assigned  to  several  teams  for  concurrent 
development  with  a  minimum  of  interaction  among  the 
teams.  Productivity  and  reliability  normally  improve 
when  interactions  are  minimized. 

Instrumented  Analysis  -  Errors  can  be  identified, 
located ,  and  removed  with  data  taken  from  the  opera¬ 
tional  system  during  execution. 

Parameterization  -  Well-designed  systems  have  many 
system-defining  values  that  need  to  be  changed  as  the 
system  evolves  through  its  life  cycle.  These  values 
(or  parameters)  define  such  items  as  the  number  and 
size  of  I/O  buffers,  the  code  designated  as  permanently 
resident  in  memory,  and  screen  formating  data.  Par¬ 
ameters  can  be  either  single  values  or  tables  of  val¬ 
ues.  Parameters  in  a  well-designed  system  can  be 
changed  at  SYSGEN  time  or  at  start-up  time  Witr.cut 
modifying  any  of  the  code  in  the  system. 


2.4.3  Supporting  Tools 

The  following  tools  facilitate  implementation. 

Compiler  -  Reliable  compilers  are  required  for 
nich-level  language  coding.  For  "unstructured" 
programming  languages,  such  as  FORTRAN,  a  preprocessor 
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Assembler  -  If  the  software  is  to  be  implemented  1  :•• 
assembly  language,  an  assembler  with  a  macro  taccl  t. 
is  essential.  Navy  standard  military  computers  must 
oe  supported. 

Linkers  and  Loaders  ~  These  programs  resolve  ext  e :  -a a 
references  among  separately  compiled  or  assembled  pr  - 
grams,  and  create  a  "load  module"  for  execution  on 
the  target  machine. 

Simulators  -  Object  modules  for  the  target  machine 
can  be  tested  on  the  host  computer  with  simulators. 
Simulators  for  Navy  standard  military  computers 
a  minimum  requirement. 

Host-Targeted  Compilers  -  An  alternative  to  simula- 
tors  are  host-targeted  compilers.  These  tools- 
use  the  source  text  created  for  the  target  computer 
and  generate  object  modules  which  can  be  run  directly 

on  the  host  computer. 

Debugger  -  Debugging  is  easier  if  it  can  be  done 
using  source  text  rather  than  object  modules.  The 
debugger  executes  the  source  text  instruction  by 
instruction.  When  an  error  is  found,  the  debugger 
translates  the  state  of  the  computer  into  information 
useful  to  the  programmer,  e.g.,  line  number  of  the 
source  text  where  the  error  occurred,  values  of  var¬ 
iables,  input  data  being  processed,  etc.  The  debugger 
also  allows  the  programmer  to  set  break  points  in 
the  source  text.  These  points  suspend  execution, 
thereby  allowing  the  programmer  to  examine  (or  modify; 
variables  before  execution  is  resumed. 

?retty  Printer  -  This  program  reformats  the  source 
text  into  a  standard  layout  which  makes  the  source 
test  easier  to  read. 

Analysis  rods  -  These  a  nc  1  de  r  0.0  r  a  s:a  •hicr. 
produce  cross  reference  listings,  maps  of  variables 
which  are  being  set  and  used,  analysis  diagnostics  ;; 
data  and  control  flew,  as  well  as  .  anous  measures  if 
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site,  complexity,  performance,  etc.  These  capabil¬ 
ities  may  be  included  as  options  in  the  compiler. 

Data  Sxtraction/Reduction  -  This  tool  instruments 
operational  programs  and  allows  information  on  dynamic 
performance  and  accuracy  to  be  extracted.  The  reduced 
data  simplifies  analysis  of  bottlenecks,  and  helps  to 
identify  poorly-performing  programs. 

System  Builder  -  This  tool  supports  the  SYSGEN  pro¬ 
cess^  It  collects  all  of  the  programs,  data  and  sys¬ 
tem  instructions  needed  to  create  an  operational  sys¬ 
tem.  It  might  perform  consistency  or  completeness 
tests,  schedule  recompilation  of  source  text,  and 
automatically  create  jobs  for  the  linker/loader. 

The  product  is  a  generated  system  for  ECS. 

Ada  Run-Time  Support  -  This  tool  would  provide  the 
run-time  functions  to  support  compiled  Ada  programs. 


2.4.4  Requirements  on  the  SEE 


Implementation  will  place  the  following  requirements  on 
the  SEE: 

Baselined  Products  -  The  baselined  products  are  the 
source  text,  object  modules,  load  modules,  and  any 
required  system  generation  information.  The  latter 
might  include  a  job  control  language  sequence  to 
create  the  system  plus  the  necessary  system  configur¬ 
ation  information  and  data. 

Non-Baselined  Data  -  This  information  includes  work- 
in-progress,  test  data,  drivers  and  stubs,  and  debug 
and  other  analysis  information  produced  by  development 
tools. 


Measurements  -  Examples  of  useful  measurements 
include  data  on  the  products  of  programming  activities, 
data  on  resources  expended,  data  on  changes  and 
errors,  and  subjective  measurements  of  the  quality  of 
the  implementation. 
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correctness  analysis  begins  oy  showing  that  the  specifica¬ 
tion  reflects  the  requirements. 

Figure  2.5-1  provides  an  overview  of  the  scope  of 
correctness  analysis  (Ferrsr.tino  and  Mills  [77];.  Many 
software  developers  are  concerned  with  testing  the  completed 
system  against  the  requirements  without  regard  for  the 
adequacy  of  the  requirements.  This  approach  tc  correctness 
analysis  is  unsatisfactory  for  the  following  reasons: 

-  The  requirements  may  be  inconsistent  or  incomplete 
for  proper  capture  of  the  intended  purpose  of  the 
system. 

-  Finding  and  correcting  errors  after  system  implemen¬ 
tation  is  much  more  costly  than  correcting  errors 
where  they  are  introduced. 

-  Correctness  analysis  improves  the  quality  of  soft¬ 
ware.  Quality  cannot  be  tested  into  a  system. 

Thus,  correctness  analysis,  as  shown  in  Figure  2. 5. 1-1, 
consists  of  continuous  analysis  throughout  the  software 
engineering  process  as  well  as  testing  of  the  implemented 
system. 


2.5.1  Characteristics 


The  main  focus  of  correctness  analysis  is  not  reduction 
in  the  number  of  errors  introduced  into  the  system,  but 
reduction  in  the  error-day  measure.  The  error-day  measure 
is  the  average  length  of  time  (in  days)  that  an  error  goes 
undetected.  A  system  with  a  short  error-day  measure  is 
likely  to  be  of  high  quality  and  low  development  cost 
because  of  reduced  reliance  on  testing  to  remove  errors. 

If  a  system  has  a  long  error-day  measure,  the  system  is 
likely  to  be  costly  to  develop  and  unreliable. 
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Figure  2.5-1 :  The  Scooe  of  Correctness  Analysis 
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Correctness  analysis  must  span  all  activities  to  minimize 
the  error-day  measure  of  a  system.  Figure  2. 5. 1-1  depicts 
this  coverage.  The  arrows  indicate  correctness  analysis 
activities  as  described  below: 

Review  of  the  requirements  for  consistency  and 
correctness.  Because  requirements  are  rarely  defined 
rigorously,  the  arrow  is  dotted.  (1  on  the  figure.) 

If  completeness  and  consistency  cannot  be  established 
at  the  requirements  level,  completeness  and  consist¬ 
ency  should  be  established  with  the  specification 
as  a  base.  (2) 

Determining  that  the  specification  correctly 
implements  the  requirements.  (3) 

Determining  that  the  system  design  correctly  imple¬ 
ments  the  specification.  (4) 

Determining  that  the  design  decomposition  does  not 
violate  the  system  design.  (5) 

Determining  that  each  unit  of  the  implemented  system 
correctly  reflects  the  detailed  design  and  that  the 
implemented  system  correctly  represents  requirements 
and  specifications.  (6  and  7) 

Correctness  analysis  must  be  an  integral  part  of  each 
phase  of  an  incremental  development  plan.  If  incremental 
development  persists  throughout  the  life  cycle,  these 
activities  apply  to  maintenance.  When  changes  are  made, 
a  full  analysis  of  the  system  is  not  needed  as  only  the 
changed  areas  and  the  areas  affected  by  the  changes  need 
to  be  analyzed. 


2.5.2  Methodologies 


The  methodologies  linked  with  correctness  analysis  are 
either  static  analysis  or  dynamic  analysis.  Static  analysis 
includes,  in  order  of  increasing  rigor,  reviews,  inspections, 
and  proofs  of  correctness.  Dynamic  analysis  includes  ail 
testing  techniques. 


Correctness  Analysis 


Face 
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Rev  lews  -  Reviews  determine  the  internal  eompiere- 
ness  and  consistency  of  system  requirements  and 
software  specification,  design  and  -est  ir.fei  -fiat  : 

They  also  assess  its  consistency  with  its  rredecess.-i 
information.  Reviews  involve  a  broad  range  of  people, 
including  developers,  managers,  users,  and  outside 
experts  or  specialists.  A  review  must  have  specific 
objectives  and  questions  to  be  addressed  (Heninger 
(73]).  The  review  findings  generate  rework  tasks 
for  the  development  group. 

Inspections  -  Inspections  evaluate  the  correctness 
of  component  level  specification,  design,  code,  test 
plans,  and  test  results.  They  are  more  formal  and 
rigorous  than  reviews.  An  inspection  involves  a 
small  group  of  people  of  a  specific  make-up,  and 
follows  a  well-defined  procedure  (Fagan  [’’5]). 

Proofs  of  Correctness  -  All  development  products 
should  be  verified  with  an  informal  proof  of  correct¬ 
ness.  Certain  critical  kernals  of  code  or  special 
applications  may  require  a  formal  proof  of  correct¬ 
ness. 

Testing  -  Dynamic  execution  of  the  system  or  system 
component  with  known  inputs  in  a  known  environment  is 
a  "test."  If  the  test  result  is  consistent  with  the 
expected  result,  the  component  is  deemed  correct  in 
the  limited  context  of  the  test.  The  following 
baselined  documents  are  created  relative  to  testing: 

-  Test  Plan  -  Defines  the  scope,  approach,  and 
resource  needed  for  testing. 

-  Test  Procedures  -  Provides  a  detailed  descrip¬ 
tion  of  the  steps  and  test  data  associated  with 
each  test  case. 

-  Test  Results  -  Documents  the  results  of  each 
test  run.  Unsuccessful  runs  trigger  trouble 
reports  which  must  be  addressed  by  the  development 
group. 

There  are  two  approaches  to  testing  —  black-oox  testing 
and  wnite-box  testing.  Black-box  testing  uses  only  knowl¬ 
edge  of  externals  { tc  the  function)  while  white-box  testing 
uses  knowledge  of  the  internal  design  of  the  function. 


Page  1-46  2.5.2  Methodologies  and  Tools:  Correctness  Analysis 

Methodologies 


Black-box  testing  uses  the  specification  to  develop 
test  cases  (Howden  [76]  )  and  is  most  appropriate  for  system 
testing  because  it  directly  demonstrates  that  the  imple¬ 
mented  system  satisfies  the  specification.  White-box  test¬ 
ing  uses  design  information  to  develop  test  cases  (Miller 
and  Melton  [75] )  and  is  most  appropriate  for  component 
testing. 

The  relationships  between  system  functions  and  compo¬ 
nent  or  system  test  cases  should  be  clearly  established. 
Then,  when  changes  are  made  to  parts  of  a  system,  a  subset 
of  test  cases  can  be  identified  which  will  test  the  system 
sufficiently.  This  process  is  called  regression  testing. 
Effective  regression  testing  is  a  good  way  to  reduce  soft¬ 
ware  development  costs. 


2.5.3  Supporting  Tools 


A  representative  set  of  tools  to  support  the  correctness 
analysis  methodologies  is  listed  in  Figure  2. 5. 3-1.  Examples 
of  all  these  tools  may  exist  today  but  not  all  of  them  could 
be  used.  In  many  categories,  they  are  not  effective  or  they 
were  implemented  in  a  narrow  environment  Such  as  for  FORTRAN 
only.  A  brief  description  of  each  tool  is  given  below. 

Performance  Model  -  Performance  models  evaluate 
system  performance  constraints  such  as  response  time. 
The  evaluation  is  performed  by  an  analytic  model  or 
simulation  model  based  on  the  system  design.  If  the 
performance  model  is  used  to  evaluate  requirements 
feasibility,  a  high-level  design  is  assumed. 
Performance  models  have  been  developed  for  many 
systems.  The  Navy  is  currently  developing  a 
generalized  modeling  tool  called  Performance  Oriented 
Design. 

Prototyping  Aid  -  Developing  an  operational 
prototype  will  allow  evaluation  of  requirements  and 
design  approaches.  Executable  design  languages  night 
be  useful  in  this  regard;  there  are  several  examples 
of  these,  such  as  APLGOL  used  on  the  LAMPS  program. 

Consistency. /Completeness  Analyzer  -  These  tools 
aid  analysis  of  inter r.ai.  lonsistency  and  completeness 
when  specif  icatior.*  requirements  are  expressed  m  a 
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Figure  2. 5. 3-1:  Methodologies  and  Tools  of 

Correctness  Analysis 
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machine- interpretable  form. 

Standards  Checker  -  Standards  checkers  perform 
static  analysis  of  code  or  documentation  and  identify 
standards  violations.  Some  tools  address  part  of 
"his  job  but  none  known  to  the  authors  would  conform 
to  Navy  MIL-STD-- 16'7  9  . 

Assertion  Analyzer  -  These  analyzers  verify  that 
code  correctly  implements  specification  by  check . ng 
the  truth  of  tne  assertions  (embedded  in  the  code) 
against  actual  program  execution. 

Symbolic  Execution  -  Symbolic  execution  is  useful 
tor  proving  "the  correctness  of  certain  classes  of 
programs.  It  involves  "executing"  them  symbolically 
to  prove  certain  assertions.  The  existing  tools  are 
aimed  primarily  at  FORTRAN  programs. 

• 

Theorem  Prover  -  Theorem  provers  automate  proof-of- 
correct.ness  techniques.  This  technology  is  not  in 
use  by  production  software  groups. 

Test  Harness  -  A  test  harness  provides  the  framework 
for  unit  testing  of  procedures.  With  it,  programmers 
can  interactively  define  the  procedure  interface, 
prepare  test  data,  run  an  instrumented  test,  and 
display  the  test  result. 

Test  Data  Generator  -  Based  on  a  given  testing 
strategy  such  as  "test  every  path,"  this  tool  will 
automatically  develop  test  cases  based  on  the  code 
(or  perhaps  the  design). 

Hardware  Simulator  -  Hardware  simulators  allow 
object  code  for  a  target  computer  to  be  tested  on  tne 
cost  computer. 

Host-Target  Compiler  -  A  software  alternative  to 
hardware  simulators  which  use  source  text  to  generate 
oo;ect  code  that  executes  cn  the  host  computer. 

Test  Results  Comparator  -  This  tool  compares  actual 
unit  test  results  against  expected  results.  It  issues 
a  trouble  report  if  the  test  results  are  not  correct. 


Environment  Simulator, Stimulator 


The  simulator 
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duplicates  che  operations!  environment  of  the  ECS  in 
a  rest  facility.  This  is  dens  before  integration 
j’th  the  sensor  and  weapon  systems.  The  shim;;  :  n  r  - 
tes^s  the  system  by  simulating  input  such  as  sensor 
and  weapon  interface  signals. 

Performance  Monitor  -  These  tools  permit  measurement 
of  system  performance  parameters,  such  as  response  time 
algorithm  processing  time,  channel  utilization,  etc. 

Data  Extraction  and  Reduction  -  These  tools  help  to 
analyze  the  system  dynamically.  During  execution, 
data  is  captured  and  stored,  and  later  reduced  by 
processing  to  create  reports  for  the  dynamic  analysis 
activity. 

Scenario  Generator  -  These  tools  control  the  complex 
parameters  which  create  the  scenarios  and  drive  the 
simulation  of  the  environment. 

Black-Box  Test  Generator  -  These  tools  generate 
functional  test  skeletons  by  using  the  specification 
of  the  software  system.  The  analyst  then  completes 
the  scenarios  by  adding  detail  to  the  skeleton.  The 
tools  should  include  sampling  techniques  to  assure 
adequate  coverage  of  the  specification. 

Reliability  Model  -  These  tools  use  the  error 
history  of  the  system  over  its  life  cycle  to  estimate 
a  reliability  measure  for  the  system. 


2.5.4  Requirements  on  the  SEE 


The  requirements  on  the  SEE  data  base,  derived  from  the 
correctness  analysis,  are  summarized  below. 

Baselined  Products  -  Test  plans,  test  procedures 
and  test  results  Tof  correctly  executed  tests)  are 
all  baselined.  They  are  controlled  by  configuration 
management.  The  results  of  inspections  and  proofs 
might  also  be  baselined. 

Nor.-Baselined  Data  -  The  non-baseiined  data  includes 
work- in-progress ,  static  analysis  data,  trouble 
reports,  and  debug  data.  Temporary  storage  of  this 
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type  of  information  is  required. 

Measurement  Data  -  A  number  of  measurements  assoc¬ 
iated  with  correctness  anlaysis  .should  be  captured. 
These  include:  number  of  modifications  to  a  unit, 
number  of  errors  found  per  unit,  number  of  test  runs, 
number  of  errors  by  error  category,  and  test  coverage. 

The  support  system  must  provide  a  framework  for  each 
tool  identified  in  Section  2.5.3.  In  particular,  tne 
demands  on  the  support  system  levied  cy  system  test  can  re 
extensive.  One  or  more  dedicated  computers  may  oe  required 
to  host  tne  environment  simulator  to  support  a  system  test 
of  an  ECS.  Special  hardware  may  also  be  required  to  inter¬ 
face  the  environment  simulation  computer  with  the  target 
computer  or  subsets  of  weapon  systems. 

2.6  Management 


Management  has  the  responsibility  of  ensuring  that  the 
software  meets  its  delivery  goals  of  schedule,  cost  and 
quality.  Figure  2.6-1  illustrates  the  management  process. 

Planning  and  organizing  resources  results  in  the  crea¬ 
tion  of  a  development  plan  which  shows  how  the  resources, 
applied  within  the  software  development  process,  will  meet 
the  delivery  goals  of  schedule,  cost  and  quality.  The  plan 
must  also  be  able  to  accomodate  modifications  due  to  author¬ 
ized  changes  and  unexpected  problems.  Monitoring  evaluates 
progress  according  to  plan,  effectiveness  of  development 
activities,  and  the  quality  of  the  products  (intermediate 
and  finals.  The  control  activity  is  used  to  take  corrective 
action  when  necessary. 


2.6.1  Characteristics 


Planning :  The  activity  of  planning  involves  estimating 

what  is  needed  to  meet  the  ob3ectives  of  the  pro]ect,  and 
then  organizing  and  allocating  the  resource  to  perform  the 
work.  Estimation  must  consider  the  size  and  complexity  of 
the  software  being  developed,  tr.e  skill  mix  and  productivity 
of  the  development  professionals,  the  schedule,  potential 
problem  areas,  and  tne  power  and  sophistication  of  the  sup- 


Page  1-5 u  2.6.1  Methodolog  ies  and  Tools.  Management 

Characteristics 

*  *  *  ■*  *  *  *  *  *  *******  *  **************************  **-****■*■******-**** 


port  resources.  Cnee  estimation  is  complete,  the  resources 
will  be  organized  and  allocated  to  do  the  work. 

Monitoring :  This  management  activity  is  used  to  guage 

the  progress  of  the  work  to  date,  the  quality  of  the  products 
to  date,  tr.e  quality  of  the  development  process,  and  the 
adherence  to  standards.  Management  must  be  constantly  aware 
of  the  expenditure  of  re  ,ource  to  meet  tne  project  coals 
and  tne  progress  of  the  work  toward  the  milestone  dates. 
Management  must  ca.<e  corrective  action  on  expenditures  or 
proqress  wr.ich  is  not  according  to  plan. 

Using  quality  assurance  techniques,  the  quality  of 
each  product  is  compared  to  a  pre-established  index  of  qual¬ 
ity.  Products  not  meeting  the  standards  would  require 
rework.  Accomplishment  against  plan  is  checked  when  pro¬ 
gress  is  evaluated.  Technical  progress  and  resources 
expended  must  be  matched  against  the  budgets  and  schedules 
of  the  development  plan,  and  deviations  marked  for  correction. 

Quality  assurance  techniques  are  also. used  to  check 
the  quality  of  the  development  process  and  adherence  to 
standards.  The  techniques  used  are  similar  to  those  of 
correctness  analysis.  Reviews,  inspections  and  test  results 
are  audited  and  analyzed  with  deviations  noted  for  correc¬ 
tive  action. 

Controlling :  Control  must  be  maintained  over  both  the 

development  process  and  the  products  of  the  process.  The 
control  of  the  process  focuses  on  meeting  the  goals  and 
objectives  (established  in  the  development  plan)  through 
the  use  of  available  resources.  Authority  is  delegated  and 
responsiblity  assigned  through  an  organizational  structure. 

The  control  of  products  focuses  on  the  products  of 
each  activity  in  the  software  development  process.  Con¬ 
figuration  management  protects  products  by  creating  a 
master  copy  (i.e.,  a  "baseline”)  against  which  controlled 
changes  are  made.  This  ensures  the  consistency  of  the 
evolving  system  as  requirements  are  defined,  specifications 
are  documented,  the  design  is  developed  and  implemented, 
and  changes  made. 
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.  the  me suremenr.s  from  prior  projects  T  •  t  a  .  r 
sources.  Examples  are  found  ir.  Bailey  and  Basi'.  i 
[40] ,  and  Putnam  •73],  Support  of  estimation 
ir/jr hodoiog ies  requires  a  data  base  of  compr enersi  »e 
measurements  including  such  software  system,  ~ararn- 
etets  as  sice  of  source  code,  source  lac.g  ;age- ,  devel¬ 
opment  resources  expended,  and  complexity  measures. 

Precedence  Networks  -  This  planning  methodology  is 
used  to  analyze  task  dependencies  and  to  determine 
the  critical  path  of  development  activities.  Such  an 
analysis  is  usually  needed  to  define  a  realistic 
schedule.  It  is  also  useful  in  evaluating  contin¬ 
gencies  and  creating  contingency  plans. 

Change  Control  -  This  is  the  core  of  conf iguration 
management.  It  controls  all  changes  to  baselined 
products.  The  approval  process  for  changes  might  be 
as  follows. 

The  written  request  for  change  is  submitted  to  the 
configuration  management  function.  It  might  come 
from  a  change  in  requirements  or  from  a  trouble 
report  documenting  a  defect. 

An  assessment  is  made  of  the  technical  feasibility 
of  the  change,  and  its  impact  on  schedule  and  budget. 

The  change  is  approved  or  disapproved  based  on  its 
value  and  cost. 

The  development  plan  is  modified  and  resources 
adjusted  to  add  approved  changes. 

The  fully  verified  change  is  entered  into  the  new 
base  1  .ine . 
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1.6.3  Supporting  Tools 

M«jny  tools  are  applicable  to  management  and  can  support 
the  methodologies  and  activities  described  acove.  Some  of 
the  more  useful  tools  for  management  include: 

Resource  Estimation  Model  -  This  software  uses  a 
data  base  of  measurements  on  past  projects,  along 
with  a  description  of  the  .new  system,  to  create 
resource  estimates  for  development. 

Automated  Precedence  Network  -  This  software  create 
precedence  network  charts  and  determines  the  critical 
path  based  on  the  input  of  detailed  milestones  and 
precedence  relations. 

Automated  WBS  -  This  tool  helps  to  create  budgets 
and  a  work  breakdown  structure. 

Schedule  Generator  -  This  tool  uses  output  from  the 
precedence  network,  and  organizational  responsibil¬ 
ities  (related  to  tne  WBS),  to  create  schedules  by 
organ izacional  entity. 

Change  Request  Tracker  -  This  tool  logs  change 
requests  when  submitted ,  tracks  them  through  the 
approval  cycle,  and  records  their  resolution. 

Resource  Scheduling  Aids  -  These  tools  permit 
resources,  such  as  computers,  conference  rooms, 
terminals,  and  test  equipment,  to  be  scheduled. 

Csage  reports  on  tne  resources  and  the  scheduling  of 
the  resources  are  the  main  functions  of  these  tools. 

Report  Generators  -  Report  generators  create 
management  reports  on  technical,  budget,  and  admini¬ 
strative  status. 


2.6,4  Requirements  on  the  SEE 


The  activity  of  management  imposes  the  following 
requirements  on  the  SEE  data  base. 
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Non--Baselined  Data  -  Significant  amounts  of  infor¬ 
mation  associated  with  the  management  must  be  kept 
temporarily.  This  information  includes  engineering 
change  requests,  trouble  reports,  resource  allocation 
plans,  actual  resource  utilization  reports,  technical 
milestone  status,  action  item  status,  and  the  results 
of  quality  assurance  reviews. 

Measurement  Data  -  Many  measurements  are  of  interest 
to  management.  These  include  the  number  of  engineering 
change  proposals  (ECP),  and  trouble  reports  (TR),  time 
to  process  an  ECP  or  TR,  resource  use  for  each  ECP 
or  TR,  resource  use  by  project  activity,  and  software 
size  and  complexity  measures. 

The  support  system  must  have  certain  minimum  capabilities 
to  support  management.  These  capabilities  go  beyond  provid¬ 
ing  for  the  tools  identified  in  Section  2.6.3.  The  support 
system  must  provide  an  authorization  mechanism  that  allows 
management  to  protect  the  project  data  base  from  outside 
influences.  It  should  also  limit  access  by  internal  users. 

On  the  other  hand,  management  must  be  able  to  monitor  all 
aspects  of  the  project  including  the  evolving  products. 


3.  An  Abbreviated  Software  Engineering  Process 


The  software  engineering  process  described  in  Sections 
1  and  2,  if  rigorously  applied,  could  significantly  improve 
development  productivity  and  software  reliability.  Optimis¬ 
tically,  it  might  allow  production  groups  to  produce  two  or 
three  times  as  much  as  they  do  now.  Unfortunately,  this 
level  of  improvement  will  not  be  enough  to  meet  the  Navy's 
projected  demands  over  the  next  ten  years.  An  order  of 
magnitude  improvement  in  productivity  (or  more;,  is  needed. 
Thus,  methods  for  shortening  the  software  engineering 
process  are  needed - 


J 
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Thus  far,  the  main  focus  of  automation  has  been  the 
mechanical  or  clerical  aspects  of  the  software  engineering 
process.  Actually,  this  semi-automates  only  a  small  part 
of  the  entire  process.  The  quickest  way  to  abbreviate  the 
process  of  developing  software  is  to  learn  how  to  adapt 
existing  software  to  new  software  systems.  This  is  analo¬ 
gous  to  pref abricated  parts,  the  technique  which  revolution¬ 
ized  the  industrial  process.  Some,  or  even  all,  of  the 
design,  implementation  and  correctness  analysis  activities 
can  be  eliminated  for  parts  of  a  software  system  under 
development . 

The  potential  for  savings  is  significant.  Although 
most  software  development  today  is  treated  like  the  first 
of  its  kind,  there  are  few  instances  where  similar  functions 
have. not  been  implemented  already.  Even  in  an  ECS,  where  the 
complex  nature  of  the  system  suggests  that  each  new  system 
is  unique,  there  is  much  common  function  from  system  to 
system.  For  instance,  command  and  control  systems  are 
largely  a  collection  of  functions  common  across  different 
C2  systems,  e.g.,  DBMS,  display,  message  processing, 
communications,  etc.  If  we  capitalized  on  this  commonality 
in  the  context  of  a  modern  software  engineering  process, 
order  of  magnitude  productivity  improvements  are  feasible. 

Two  concepts  which  provide  a  basis  for  reusable  software 
are  common  components  and  application  skeletons.  Common 
components  are  programs  which  embody  a  certain  function  or 
class  of  functions  which  might  be  useful  in  several  systems. 
(An  example  is  a  data  base  management  system.)  An  applica¬ 
tion  skeleton  is  a  partly  implemented  software  system 
designed  for  a  class  of  application.  It  can  be  tailored 
to  a  specific  application  in  the  class.  An  example  is  a 
sim/stim  system  skeleton  comprising  simulation  problem 
control,  physical  models,  and  a  man/machine  interface  for 
simulation  control.  However,  it  requires  developing  specific 
weapons  simulation  code  and  interfaces  to  the  target  ECS 
of  concern.  The  sim/stim  application  skeleton  might  repre¬ 
sent  "  of  the  completed  system. 

For  common  components  and  application  skeletons  to 
oecorae  a  real  force  in  productivity  improvement,  several 
conditions  must  be  met.  Just  as  industry  had  to  have 
standards  for  the  use  of  prefabricated  parts,  common  com¬ 
ponents  and  application  skeletons  will  also  require  rigor¬ 
ous  standards.  These  standards  will  have  to  address  inter¬ 
face  and  development  guidelines.  Once  standards  are  estab- 
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Other  tools  to  aid  efficient  tailoring  of  common  components 
or  application  skeletons  also  will  be  needed. 

The  software  engineering  process  described  in  Sections 
1  and  2  provides  contextual  requirements  for  a  SEE.  The 
full  support  of  common  components  and  application  skeletons 
also  is  a  requirement  on  the  Navy  SEE.  This  support  can 
help  the  Navy  meet  its  pro jected* needs  for  software. 
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In  ?att  I,  a  software  engineering  environment  a:-T 
•-■as  characterised  as  an  integrated  system  consisting  oi 
compu  .er -based  support  system  and  lata  base.  The  purpose 
of  me  SEE  is  to  support  all  personnel  involved  in  the 
development  and  continuing  adaptation  of  software,  accor¬ 
ding  to  a  well-defined  doctrine  of  software  engineering 
disciplines.  Tart  i  outlined  such  a  doctrine  to  provide 
the  context  for  the  SEE  requirements.  Part  II  provides 
requirements  for  the  SEE. 

Although  the  approach  taken  in  this  requirements 
document  assume?  a  close  tie  of  the  SEE  requirements  .c  a 
unified  set  of  software  engineering  disciplines,  nor  all 
efforts  to  build  environments  have  followed  this  line.  One 
.....  terna c ’  ve  is  the  so-called  "tool  kit"  approach  wherein  a 
set  of  tool?  (possibly  integrated)  is  provided,  * i tn  r.o 
implied  constraints  on  the  choice  of  methodologies  or  -  :e 
of  the  tools.  An  example  of  a  tool  kit  approach  is  the 
Unix  Programmer's  Workbench  ( Do  lor t a  [76]).  The  tool  kit 
approach  is  viable  for  some  environments  supporting  code 
generation,  When  requirements  analysis,  specification, 
and  design  are  to  be  included,  the  tool  kit  approach  is 
inadequate  as  these  activities  involve  a  high  degree  of 
intellectual  and  creative  activity. 

The  primary  characteristic  of  the  SEE,  as  defined  in 
this  document,  is  that  it  is  methodology-driven.  However, 
several  requirements  are  included  which  are  derived  from 
useful  tool  kit  concepts.  For  instance,  tools  to  build 
tools  have  been  proven  valuable  in  tool  ki-t  approaches  and 
are  included  in  the  SEE  requirements. 

The  SEE  must  satisfy  several  general  requirements.  In 
summary,  they  are: 

ScoDe  -  The  SEE  must  support  all  activities  of  the 
life  cycle  of  software  as  defined  in  Section  1.1. 

App  1 1  cat  ion  -  The  SEE  must  adequately  support,  the 
development  and  continuing  adaptation  of  Navy  ECS 

:.ehostar.ie  -  The  surcert  svstem  and  its  data  base 
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must  be  able  to  be  rehosted  on  commercial  and  mili¬ 
tary  computers. 

Evolution  -  The  SEE  must  be  flexibly  designed 
as  software  engineering  methodologies  and  tools  are 
still  evolving. 

Re-use  -  The  SEE  must  encourage  the  capture  of 
proven  designs  and  implementations  for  re-use 
without  re-invention 

Re  liability/ Avail ability  -  The  support  system 
must  be  reliable  and  stable  enough  to  support 
long  periods  of  uninterrupted  operation. 

The  SEE  requirements  are  described  in  the  following 
subsections.  Section  1  addresses  the  SEE  data  base.  It 
describes  the  content  and  different  views  of  data  that 
must  be  supported.  Section  2  addresses  the  requirements 
for  the  support  system.  These  requirements  are  described 
in  terms  of  characteristics  of  external  interfaces,  func¬ 
tional  capability,  performance  constraints,  and  design 
constraints . 
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Data  Base 


The  data  oase-  of  the  SEE  is  its  major  integrating 
element.  It  will  contain  the  current  state  of  the  software 
system,  the  current  state  of  the  development  process,  and 
historical  data  reflecting  previous  states  of  development. 

In  short,  it  will  retain  all  the  information  on  the  activi¬ 
ties  of  the  various  personnel  working  on  a  project. 

The  clear  implication  is  that  the  SEE  data  bate  will 
contain  far  more  data  than  currently  stored  in  library 
systems  and  specialized  files  today.  For  this  reason,  the 
design  of  the  data  base  and  its  relation  to  the  support 
system  components  is  a  key  concern  in  the  implementation 
of  a  modern  SEE. 

This  section  of  the  document  presents  requirements  fcr 
the  SEE  data  base.  An  effort  has  been  made  to  avoid  any 
design  implications  which  might  overly  constrain  future 
SEE  designs.  Therefore,  the  contents  of  the  data  base  and 
relations  among  data  objects  in  the  contents,  are 
described  but  no  logical  or  physical  structure  for  the 
data  is  imposed. 

The  contents  of  the  SEE  data  base  have  been  put  into 
categories,  rather  than  simply  listed,  to  aid  in  understanding 
the  data  base.  Many  choices  for  categories  were  possible. 

The  categories  finally  chosen  represent  classes  of  data 
having  common  control  attributes.  As  an  example,  the 
"baselined"  category  contains  all  data  objects  which  will 
be  controlled  by  configuration  management.  The  five  major 
categories  chosen  for  data  objects  are: 

Baselined  -  Any  data  object  considered  to  be  a 
part  of  the  software  system  baseline  and  thus 
under  control  of  configuration  management. 

Non-baselined  -  Any  information  which  is  transient 
or  represents  "work-in-progress"  towards  a 
baselined  object. 

Measurement  -  Metrics  derived  from  the  development 
process  activities  for  use  by  management,  software 
analysis,  or  historical  quantitative  analysis. 


Archive  -  Any  quantitative  or  qualitative  data  from 
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any  of  the  other  four  categories  retained  for 
historical  purposes. 

Support  System  Library  -  All  of  the  software  and  data 
associated  with  the  support  system  including  tutorial 
data,  standard  error  messages,  and  SYSGEN  data. 

Bus  ides  the  view  of  the  data  base  defined  by  the  above 
categories,  macro  relations  and  micro  relations  must  also  be 
supported.  These  views  are  defined  in  the  relations  section 
of  tKe  data  base  description  as  macro  relations , ( those 
relations  that  encompass  a  large  number  of  data  base  objects). 
There  are  also  many  micro  relations  (those  affecting  small 
numbers  of  objects)  that  must  be  defined  in  the  data  base 
design;  these  are  also  described. 

The  following  sections  on  the  data  base  contents  and 
relations  capture  the  essentials  of  the  SEE  data  base. 

However,  many  details  have  been  omitted  due  to  the  magnitude 
of  completely  defining  all  data  and  data  relations.  It  is 
felt  that  the  degree  of  detail  is  sufficient  for  the  intended 
purpose  of  this  document. 


1.1  Contents 


The  contents  of  the  SEE  data  base  are  described  below 
in  the  five  categories  outlined  in  .Section  1.  The  contents 
are  described  in  terms  of  coarse  objects,  e.g.,  design 
information,  test  plans,  and  temporary  source  areas. 

A  standard  format  is  used  for  all  data  object  descriptions 
to  permit  conciseness  and  ease  of  reference;  the  format  is 
illustrated  below. 

OBJECT  NAME  ( * ' ;  description  of  the  data  object. 

[List  of  undefined  data  items  or 
elements  composing  the  data  object:.] 

rjrms :  [text  or  tables  or  graphics 

or  language  or  encoded.] 

Reference :  [reference  to  discussion 

relating  to  data  object  in  Part  I 
or  II. ) 
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ones  are  not. 

2.  The  term  "text"  under  Form ( s )  means  English  prose. 

3.  The  term  "language"  covers  all  formal  languages  used 
in  a  SEE:  a  formal  grammar  structure,  a  formal 
semantics  language,  formal  mathematical  expressions, 
JCL  (job  control  language)  procedures,  or  formal 
programming  languages. 

4.  The  term  "encoded"  refers  to  computer-created 
executable  code  which  is  either  translated  from 
source  text  or  combined  with  other  executable 
code  modules  to  create  executable  load  modules. 


1.1.1<  Baselined  Products 


A  baselined  product  is  any  data  object  which  is  "owned" 
by  management  and  controlled  by  the  configuration  manage¬ 
ment  process.  This  implies  that  baselined  products  persist 
over  the  life  of  the  software  system  and  that  changes  to 
these  objects  are  controlled  very  closely.  The  SEE  must 
provide  a  means  to  manage  change  deltas  to  baselined  prod¬ 
ucts  such  that  an  audit  trail  is  possible. 

In  development  projects  today,  the  baselined  products 
are  the  source  and  object  code,  generated  systems,  and 
supporting  documentation.  Some  of  these  baselined  products 
are  in  electronic  form,  while  others  may  be  maintained  as 
printed  documents.  In  the  SEE,  all  baselined  products  will 
be  maintained  in  electronic  form  in  the  SEE  data  base. 

Printed  documents  can  be  created  at  any  time  using  the  infor¬ 
mation  stored  in  the  SEE  data  base. 

The  baselined  products  are  described  below,  organi?;ed 
by  the  development  process  activity  which  creates  them. 

Requirements  Analysis 

SEMANTICS  INFORMATION  ,R):  The  captured  semantics 
of  the  requirements  for  the  software  system. 


A. 
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******************  ***************************************** 


[Definition  of  terms,  relations  among  terras, 
references  to  documents  containing  the 
requirement,  references  to  other  base¬ 
lined  products  for  traceability] 

Forra(s):  text,  language,  graphics 

Reference:  1.2.1 


B.  Specification 


SOFTWARE  SYSTEM  SPECIFICATION  (R):  The  description 

of  what  the  software  system  is  to  do;  the  speci¬ 
fication  must  be  written  in  a  formal  notation. 

[External  interfaces,  operational  modes,  output 
functions] 

Form( s ) :  text,  tables,  language,  graphics 


Reference:  1.2.2 


C.  Design 


SOFTWARE  DESIGN  (R):  The  description  of  how  the 
system  is  to  be  implemented;  the  description 
must  be  written  in  a  formal  notation. 

[Module  hierarchy,  module  specifications, 
abstract  data  structures,  process  design 
language  <  PDL ) ] 

Forra( s ) :  text,  language,  graphics 
Reference:  1.2.3 


D.  Implementation 


SOURCE  CODE  ( R) :  The  source  code  for  all  programs; 
the  code  Ts  written  in  the  appropriate  program¬ 
ming  language. 


a 


r 
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Poem (  s  )  :  language 

Re  'bronco  :  -1.1.4 
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F o  oil  (  3  :  or coaed 

Reference :  *,2.4 


In  •:  a  Base  :  (intents 

.'.iseluied  Products 


PA'r’C'jFS  7  0  OB.T£CT  CODE  :  0  ■  :  Exec  at  ah '•  ->  pctcr.  - 
either  v rTt t. e r  n ^  j  - e  ,ne rj*.  ;.ii  t : oc. r-  c 
translated  £  com  baselined  source  code. 


[executable  code ,  external  references. ,  static 
analysis  data;  identifier  for  source  coca 
bexr-3  corrected,  tctoi  identifier,  and  ....pro-' 
priate  version  nu;i,bors 1 

fonn(s):  encoded 

Reference:  1.1.4 


1  Occasionally  software-  errors  in  an  ECS  will  r?qu re  iitune- 
d  rate  <txes,  and  the  correction  cannot  be  hand  !•;•  1  qu  rckly 
through  the  normal  error  correction  cycle.  Such  an  x. .me¬ 
diate  fix  is  called  a  "patch  "  Patching  *s  no  tor  rous  for 
.  ts  introduct  xor*  of  adcit  ->nal  errors  because  the  rater, 
it  '•  <;•  solution,  was  ..-.adequately  analyzed  arc 
rose  had  and  rested  (suctle  interaction  &  r  w  o  *- .-t  a.e  '  s  pe  - 
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Baselined  Products 


•?Y5JE.V  DATA  '  R)  :  Any  data  required  by  the  system 

generation  tools  to  create  system  load  modules 
including  parameters  for  operating  systems, 
executives,  or  conf igurat  ion  definition. 

Form ( s ) ;  table,  encoded,  language 

Reference :  1.2.4 

SYSTEM  LOAD  MODULE  (0):  An  image  of  the  software 
system  in  machine-executable  form. 

Form ( s ) ;  encoded 

Reference :  1.2.4 


Correctness  Analysis 

CORRECTNESS  ANALYSIS  PLAN  (R);  A  description 
oE  the  total corr*  :tness  analysis 
approach  to  be  t  _n  for  requirements 
analysis,  specification,  design  and 
implementation;  the  plan  will  also  include 
resource  requirements  and  schedules. 

Form ( s ) ;  text 

Reference ;  1.2.5 


TEST  PLAN  ( R) ;  A  description  of  the  accroach 
to  oe  taken  specifically  for  system  test; 
it  will  include  resource  requirements  and 
schedules . 

?o  rm I s  )  :  text 


Reference :  1.2.5 

TEST  PROCEDURES  VR);  Description  of  the 

individual  tests  making  up  system  rest 
and  unit  tests. 


■-  * 


.  * 


■»  ' 


Re  ter'-nce  :  I .  *1  5 


'.ITS  [Rj_:  TV.;';  Vrt:.,v. 

T^nr.  i  s  •  ;  text,  encoded 

vjiervp.c?.;  I .  2  .  5 


c  :  o  r  r  o  < 
jrocedv.  -  e . 

rorm(  s  )  ;  text,  encoded 
3e_f  e rence :  1.2.5 


:  CCmR  Ct'TN  jJ).  Form*', 

a  design  jv  ar  Implemented 


nagemenc 


DEVELOPMENT  PLAN  (K):  The.  current  plan  governing 
all  development  or  continuing  adaptation 
activities. 

[Organization,  work  breakdown 
structure,  resource  estimates,  budgets, 
progress  status,  and  schedules] 

form (sd  text,  tables,  graphics 

Reference;  1.2.6 


"TAN. LARDS  ' 0 ; :  The  current  Navy  cr  project 
standards  for  requirements,  specif icatt 
design,  implementation  : program  code  an 
test),  correctness  analysis  of  all  phases, 
quality  assurance  1A '  ,  configuration  manage 
rnen.t  (CM),  and  management. 
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Form( s ) :  text,  tables 
Reference:  1.2.6 


SCP/TR  LOG  (O):  A  log  of  the  status  of  all  engineer- 
ing  change  proposals  or  trouble  reports. 

[Date  of  acceptance,  organizational  entity 
assigned,  date  completed  coding,  etc.) 

Form( s ) :  text 

Reference:  1.2.6 


G.  General 


DERIVATIVE  DOCUMENTS  (0):  Data  objects  used  to 
generate  any  standard  documentation,  e.g., 
a  User's  Manual  which  might  be  derived  from 
information  in  the  specification  or  design 
data  objects. 

[User's  manuals,  systems  programmer  manuals, 
SECNAVINST  3560.1  documents,  etc.] 

Form(s) :  text,  tables,  graphics,  language 


DOCUMENT  TEMPLATES  (0 ) :  Shell  of  standard  documents 
that  can  be  filled  from  other  baselined  data 
objects  to  create  derivative  documents. 

Form(  s  ) :  text,  encoded-' 


AUXILIARY  DOCUMENTS  (0):  Documents  which  are  not 
derived  from  baselined  data  objects  and  which 
may  be  defined  as  baselined  data  objects, 
e.g. ,  externally-created  documents  entered  via 
the  SEE  text  editor. 


Form( s  ? :  text,  tables,  graphics,  language 
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ft************************************************************* 


1.1.2  Non-Baselined  Data 


The  salient  characteristic  of  non-baselined  data  is 
that  it  is  temporary  in  nature  (i.e.,  working  material), 
and  is  still  in  the  iterative  process.  People  with  assigned 
work  must  have  space  to  work.  These  spaces  are  used  to 
store  work- in-process,  results  of  analysis  runs,  schedules, 
etc.  Devices  such  as  "mailboxes"  (for  message  communication 
among  project  members)  would  also  be  included  in  this 
category. 

An  individual  space  should  be  defined  such  that  data 
objects  within  it  are  "owned"  by  the  individual  and  access 
by  others  is  controlled  by  the  individual.  This  space 
access  must  not  be  so  restrictive  as  to  limit  management 
review  of  technical  status. 

Examples  of  data  objects  which  might  reside  in  work¬ 
spaces  are  described  below  by  each  development  process 
activity. 

A.  Requirements  Analysis 

TRIAL  DESIGN  ( 0 ) :  Preliminary  designs  of  sufficient 
detail  to  support  analysis  of  the  feasibility 
of  requirements. 

Form(s ) :  text,  language,  graphics 
Reference :  1.2.1 


MODEL  INPUT  (0) :  Model  input  parameters  describing 
a  trial  design. 

Form (.s ) :  text,  language 

Reference:  I.2..1 


MODEL  RESULTS  (0):  Results  of  a  modeling  run 
evaluating  a  trial  design. 

Formjs):  text,  tafcie 


Reference : 


1.2.1 
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PROTOTYPE  (0):  An  operational  prototype  of  a  soft¬ 
ware  system. 

Form( s ) :  language 

Reference:  1.2.1 


SEMANTICS  ERROR  LIST  (0):  A  list  of  incomplete 
or  inconsistent  areas  identified  in  the 
semantics  information  by  a  semantics  analysis 
tool. 

Fonn(s ) :  text 
Reference:  1.2.1 


B.  Specification 


PARTIAL  SPECIFICATION  10)?  A  specification,  or 

modifications,  leading  to  a  baselined  specif¬ 
ication. 

Form(s ) :  text,  tables,  language,  graphics 
Reference:  1.2.2 


SPECIFICATION  ERROR  LIST  (0):  A  list  of  incomplete, 
inconsistent,  or  syntactically  incorrect  in¬ 
formation  comprising  the  specification. 

Form( s ) :  text,  table 


Reference:  1.2.2 


C.  Design 


PARTIAL  DESIGN  (0):  An  incomplete  software  design, 
or  design  modifications,  leading  to  a  baselined 
software  design. 
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Form( s ) :  text,  language,  graphics 
Reference:  1.2.3 

DATA  FLOW  DIAGRAMS  ( 0 ) :  A  graph  diagramming  the 
various  states  and  transformation  of  data  as 
it  passes  from  input  to  output. 

Form(s):  text,  graphics 

Reference:  1.2.3 


•HIERARCHY  CHARTS  (0):  A  directed  graph  depicting  a 
hierarchic  relation  among  software  components. 

Form(s) :  text,  graphics 

Reference:  1.2.3 


D.  Implementation 


PARTIAL  PROGRAMS  (0):  Prior  to  baselining:  An 
untested  program,  a  partially  developed 
program,  or  a  modification  for  a  baselined 
program. 

Porm(s) :  language ,  encoded 
Reference:  1.2.4 


STUBS  ( 0 ) :  Stubs  used  in  unit  testing  of  a  program. 
Form(s) :  language 
Reference:  1.2.4,  1.2.5 

STATIC  ANALYSIS  DATA  (0):  Output  of  a  static  analyzer 
run  against  a  partial  program. 


Fora( s ) :  text,  tables 
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Reference :  1.2.5 

DEBUG  DATA  ( 0 ) :  Output  of  a  debug  run  against  a 
partial  program. 

?orm( s ) :  text/  encoded 

Reference :  1.2.4 

E.  Correctness  Analysis 

PARTIAL  TEST  PROCEDURES  (O)  :  Test  procedures  in 
development  prior  to  baselining. 

Form( s ) ;  text 

Reference:  1.2.5 

INVALID  TEST  RESULTS  (0) :  Results  of  test  runs 
against  a  partial  program. 

Form( s ) :  text,  encoded 

Reference :  1.2.5 

TROUBLE  REPORTS  (0):  A  report  of  an  error  detected 
in  the  baselined  software  system. 

Form( s ) :  text 

Reference:  1.2.5,  1.2.6 


F.  Management 

COMPUTER  SCHEDULE  (0):  Current  schedule  for  com- 
outer  use  by  various  organizational  units. 

Form( s ) :  text 


Reference:  1.2.6 
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BUDGET  TO  ACTUALS  (0):  An  up-to-date  comparison 
of  actual  resource  used  against  budgeted 
resources,  including  manpower,  time,  and  com¬ 
puter  resources. 

Form( s ) :  text,  tables,  graphics 

Reference:  1.2.6. 


MILESTONES  (0):  An  up-to-date  record  of  status 

against  milestones  as  defined  in  the  baselined 
development  plan. 

Form(s) :  text,  table,  graphics 

Reference:  1.2.6 


ALTERNATIVE  PLAN  ESTIMATES  (0) :  Resource 

estimations  associated  with  alternate  plans 
for  recovering  from  unexpected  delays  or 
resource  expenditures. 

Form(s) ;  text 

Reference:  1.2.6 


G.  General 


BULLETIN/MAIL  BOX  (0):  A  mechanism  for  broadcasting 
news  of  system  or  project  interest,  or  for 
sending  a  message  from  one  individual  to 
another;  (optionally)  displayed  on  the 
interactive  text  device  or  included 
on  any  user-generated  output. 


Form( s ) :  text 
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1.1.3  Measurement  Data 


Measurements  ace  lata  objects  of  a  quantitative  nature 
representing  some  characteristic  of  the  development  process 
or  the  software  product-  This  type  ot  lata  might  be  used  by 
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?he  measurement  cd_  net?  described  below  in  the  p-odcct 

-  pencass  subcategor or,  are  static  in  nature  as  they 

..  3 present  a  quantitative  measurement  at  se  ne  point  in  tine, 
r  ; r  the  measurements  to  have  meaning  uialyt.  ica.lly ,  it  must 
b>.>  possible  to  determi  le  the  time  derivative  (i.e.,  cate 
'.i  cr.ange)  of  many  of  the-  objects.  This  means  the  SEE 
rust  time-tag  measurements  before  they  are  stored.  The 
SEE  data  case  must  be  aola  to  store  sequences  of  time-tagged 
measurements  representing  an  object  type. 

A.  Product  Measurements 

Examples  of  measurement  data  in  the  product  subcategory 
are  given  below. 


NUMBER  OF  SEMANTIC  ENTITIES  (0):  A  count  of  the 

semantit  entities  in" the  ’Semantics  Information- 

Reference;  1.2.1 


w 


I 

f 

/ 
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NUMBER  OF  SEMANTIC  RELATIONS  (0):  A  count  of  the 
one-to-one  relationships  among  terms  in  the 
semantics  information.  The  number  of  semantic 
entities  and  the  number  of  semantic  relations 

provide  a  measure  of  complexity.  r 

V 

Reference:  1.2.1 


NUMBER  OF  SPECIFICATION  FUNCTIONS  (0):  A  count  of 

the  distinct  functions  identified  in  the  speci¬ 
fication. 


NUMBER  OF  MISSING  REQUIREMENTS  (0):  A  count  of  the 
specification  inputs,  outputs,  operational 
modes,  functions,  or  design  constraints  for 
which  no  traceable  requirement  has  been 
identified  through  the  semantics  information. 

Reference:  1.2.1,  1.2.2 


NUMBER  OF  MODULES  (0) :  A  count  of  the  modules  defined 
in  the  system  level  design. 

Reference :  1.2.3 

NUMBER  OF  PROGRAMS  (0):  A  count  of  the  programs  in 
the  detail  level  design. 

Reference :  1.2.3 


HUMBER  OF  LINES  OF  SOURCE  TEXT  (0);  A  count  of  the 
lines  c*'  non-commentary  source  text  related  to 
the  operational  software  system. 

Reference :  1,2.  '. 


A 
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RESIDENT  MEMORY  (0):  A  count  of  the  number  of 

bytes  of  memory  required  by  the  nucleus  and 
transient  areas  of  the  operational  system. 

Reference:  1.2.4 


NUMBER  OF  KNOWN  DISCREPANCIES  (0):  A  count  of 
the  known  discrepancies  between  the  specifica¬ 
tion  and  the  requirements,  or  between  the  im¬ 
plemented  software  and  the  specification. 

Reference:  1.2 


RELIABILITY  (O):  A  statistical  estimate  of  soft¬ 
ware  component  or  system  reliability  based  on 
error  history  and  (perhaps)  complexity  measures. 

Reference:  1.2.5 


B.  Process  Measurements 


NUMBER  OF  ERRORS  FOUND  (0):  A  count  of  the  number  of 
errors  found  in  the  software  products. 

[by  product  (specification,  design,  etc.);  by 
increment,  release  or  version;  by  types  of 
error;  by  severity  (i.e.,  effort  needed  to 
fix)  ] 

Reference:  1.2 


MAN  MONTHS  EXPENDED  (0):  A  count  of  the  man-months 
'  o£  effort  expended. 

[by  organizational  entity;  by  life  cycle 
activity;  by  product;  by  increment,  release, 
or  version;  by  individual] 


Reference:  1.2.6 


1.1.3 
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INDIVIDUAL  PRODUCTIVITY  (0):  A  count  of  the  man- 

months  of  effort  expended  in  certain  activities. 

[by  product,  by  version] 

Reference:  1.2.6 


NUMBER  OF  CHANGES  (0):  A  count  of  the  number  of 
changes  made  to  a  baselined  product. 

[by  release,  by  version,  by  life  cycle 
activity  within  increment] 


NUMBER  OF  COMPILATIONS  (0):  A  count  of  the  number 
of  compilations  of  a  program  before  accep¬ 
tance  for  baselining. 


NUMBER  OF  TESTS  (0):  A  count  of  the  number  of  unit 
tests  of:  a  program  before  success. 


1.1.4  Archive  Data 


Archive  data  will  contain  a  history  of  all  projects 
including  the  project's  data  base  and  especially  baselined 
data.  Archive  data  should  be  kept  after  the  development 
phase  and  probably  after  the  operational  life  of  the  system. 
Analysis  of  it  will  help  software  professionals  learn  from 
the  past,  both  from  successes  and  from  failures.  It  should 
be  mandatory  for  the  baselined  data  (of  the  developed 
system)  to  be  available,  either  online  or  in  archive  form, 
during  life  cycle  support.  Archive  data,  because  of  its 
potential  volume  and  infrequent  access,  will  be  stored 
off-line.  Media  such  as  magnetic  tape  or  microfilm  would 
be  appropriate. 

Archive  data  might  include  data  objects  from  any  of  the 
other  four  categories.  For  this  reason,  nc  data  objects  are 
explicitly  defined  for  this  category. 

One  needs  to  be  able  to  find  and  retrieve  the  desired 
data  objects  tc  make  archived  data  useful.  Ar.  index  of 
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ui.  cawed  data  must  be  created  and 

should  be  based  on  the  time  of  archival,  the  project  name, 
the  software  system  name  (as  modified  by  release  and 
version);  all  of  these  indices  are  needed.  The  index  must 
contain  a  brief  description  of  the  data  object  and  pointers 
to  where  the  data  is  stored. 


1.1.5  Support  System  Library 


A  support  system  is  an  integrated  set  of  computer-bas 
tools  supporting  all  of  the  activities  of  the  software  eng 
neering  process.  The  support  system  library  will  contain 
all  of  the  tools  comprising  the  support  system;  it  will 
also  contain  data  assumed  to  be  part  of  the  support  system 
such  as  tutorial  information,  error  information  or  SYSGEN 
data.  The  support  system  library  is  considered  baseline 
data;  therefore,  the  library  and  all  modifications  to  it  are 
under  configuration  management. 

The  data  objects  of  the  support  system  library  category 
are  described  below. 

SYSTEM  SOFTWARE  (R):  Systems  software  components 

including  operating  systems,  data  base  manage¬ 
ment  system,  telecommunications  handlers, 
utilities,  etc. 

[specifications,  design,  source  code,  object 
code,  etc.] 

Form( s ) :  text,  language,  encoded 
Reference:  II.  2. 2.1 


GENERAL  SERVICES  (R):  Software  components  of  the 

support  system  for  general  application  use  such 
as  a  text  editor  and  document  generator. 

[specifications,  design,  source  code,  object 
code,  etc.] 


Form( s ) :  text,  language,  encoded 
Reference :  II. 2. 2. 2.1 


system  -:.;i.ary 

■t<r*'***^***tty**#ii*»*#*5r*'h****i  *★*★***  v.  **»■*■*  ********  k  • 


•TT  v’  IT-'-SFFCr  FTC  TOOLS  {  ~  ■  :  A.:v  so:  tvs 


cu.t  :.'rx  \..ie  3 , 

■  specif icatin,  design,  source  cede , 
code,  etc.] 

Form ( s ) :  text,  language,  encoded 
Reference:  11.2.2.2.2 


USER-GENERATED  TOOLS  (0):  Any  tool  created  by  an 

Individual  or  project  for  limited  application, 

[specification,  design,  source  .  >  de,  object 

code,  etc.] 

Fonr.(  s  ) :  text,  language,  encoded 


APPLICATION  PARADIGMS  (0):  Reuseable  components  o: 
program  skeletons  used  to  reduce  development 
time  and  cost. 

[specification,  design,  etc.] 

Form( s  > ;  text,  language,  encoded 

Reference:  II. 2. 2. 2. 3 


TUTORIALS  (R):  Information  provided  when  "help"  is 
requested  by  an  interactive  us-'c. 

Form  (  5  '•  :  text 


1.2  Relations  Among  Data  Rase  Objects 


One  of  cne  unique  aspects  of  the  SEE  data  base  is  the 
extensive  degree  of  interrelation  among  the  data  objects 
described  : n  Section  II.  1.1.  These  interrelations  will 
gr-.atl  y  complicate  the  job  of  designing  the  data  base 
s true-  ire  and  lata  -ase  management  system  .DBMS),  The 


Page  11-22  1.2  Data  Base:  Relations  Among  Objects 


purpose  of  this  section  is  to  describe  the  relations  that 
must  be  accommodated  in  the  SEE  data  base. 

Not  only  must  one-to-one  and  one-to-raany  relations  be 
accommodated,  as  in  a  hierarchically  structured  data  base, 
but  many-to-raany  relations  must  be  accommodated  as  well. 

For  example,  the  "linked  from"  relationship  is  many-to-many 
because  one  object  module  can  be  linked  from  many  other 
object  modules,  and  many  object  modules  can  be  linked  from 
a  single  object  module.  If  the  number  of  many-to-raany 
relations  in  the  data  base  is  high,  a  relational  DBMS  for 
the  SEE  might  be  more  appropriate  than  a  hierarchical 
DBMS.  The  issue  of  hierarchical  versus  relational  organi¬ 
zation  for  the  data  base  needs  further  investigation. 
Analysis  is  needed  of  such  key  factors  as  how  the  size  of 
the  data  base  and  the  activity  volumes  impact  performance. 

Two  classifications  are  used  to  describe  the  SEE  data 
base:  macro  relations  and  micro  relations.  Macro  relations 
tie  many  objects  of  the  data  base  together  to  form  a  "raeta 
object,"  an  object  with  many  parts  which  need  to  be  refer¬ 
enced  as  whole.  Macro  relation  data  will  allow  a  meta 
object  to  be  addressed  with  one  reference.  An  example  of 
a  meta  object  would  be  a  list  of  all  baselined  source  pro¬ 
cedures  belonging  to  Project  A.  Micro  relations  reference 
two  or  more  objects  in  the  data  base. 


1.2.1  Macro  Relations 


There  are  nine  macro  relations.  Five  are  categories 
described  in  Section  II. 1.1:  baseline  data  (and  products), 
non-baseline  data,  measurement  data,  archive  data,  and  the 
support  system  library.  The  other  four  macro  relations 
are:  project,  release,  version,  and  increment.  Since  the 

first  five  categories  have  been  described,  only  the  last 
four  are  defined  below. 

Project  -  A  project  is  an  organizational  entity 
with  an  assigned  development  responsibility. 
Therefore,  a  project  macro  relation  identifies  all 
the  SEE  data  objects  belonging  to  (controlled  by) 
the  project.  These  might  include  data  objects  in 
the  baseline,  non-baseline,  measurements,  archive, 
and  support  system  categories. 
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Re  lease  -  A  release  xO  a  specif i c  software  system 
which  has  been  deployed  and  *s  operational.  A 
software  system  may  nave  many  releases  over  its 
life  cycle,  and  would  include  ail  objects  belong '.‘ic 
to  a  project,  but  is  normally  a  subset  of  a  project. 

Vers  ion  -  A  version  is  a  variation  of  a  release. 
Different  versions  of  the  came  release  might  be 
required  to  support  multiple  {but  slightly  different, 
physical  installations  of  the  system. 

Increment  -  An  increment  is  a  management  unit  of  a 
project  associated  with  incremental  development. 

There  may  be  several  increments  leading  to  a  single 
release,  or  an  increment  could  equal  a  release 
after  the  system  is  operational. 

It  would  simplify  processing  associated  with  macro 
relations  if  they  could  be  represented  in  some  hierarchic 
structure,  but  such  a  hierarchical  ordering  is  not  practical 
for  macro  relations.  As  an  example,  it  would  be  convenient 
to  associate  a  release  of  a  software  system  with  a  project. 
However,  in  practice,  many  releases  might  be  controlled 
by  a  single  project  and,  for  very  large  systems,  many 
projects  might  be  associated  with  a  single  release.  Simi¬ 
larly,  many  releases  of  possibly  different  systems  might 
use  the  same  version  of  a  baselined  subsystem  controlled  by 
another  project,  and  many  versions  of  a  system  might  be 
associated  with  one  release. 

Macro  relations  can  be  thought  of  as  different  views 
(possibly  overlapping)  of  large  pieces  of  the  SEE  data 
base.  The  many-to-many  nature  of  these  views  again  suggests 
that  a  relational  approach  might  be  better  than  a  hierarchical 
approach  when  designing  the  SEE  data  base. 


1.2.2  Micro  Relations 


There  are  many  limited  relations  among  data  objects 
that  should  be  supported  by  the  SEE.  These  relations  are 
called  micro  relations  because  they  are  significant  as 
small  sets  of  data  objects.  These  micro  relations  are 
briefly  described  below. 

Traceability  -  Traceability  relates  individual 
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design,  and  source  code  which  implement  them,  and  to 
the  data  which  demonstrates  their  correctness. 

This  capability  is  useful  in  assessing  the  impact 
of  requirements  changes,  and  in  defining  regression 
test  sets  for  changes  to  the  baseline. 

One  method  of  attaining  traceability  is  through  use 
of  the  relational  nature  of  the  semantics  tools 
defined  for  requirements  analysis.  These  tools  can 
be  used  to  establish  references  to  the  specification, 
design,  source  text,  and  to  test  baselined  data 
objects. 

The  SEE  also  shall  provide  for  traceability  directly 
through  the  use  of  micro  relations.  The  traceability 
relation  will  allow  a  direct  tie  of  requirements  to 
baselined  objects,  or  an  indirect  tie  using  an 
associative  attribute  as  shown  in  Figure  1.2. 2-1. 

Derivation  -  Many  data  objects  are  related  because 
they  are  derived  from  other  data  objects  in  the  data 
base.  In  some  cases,  it  is  important  to  retain  this 
relation  explicitly  to  simplify  the  later  use  or 
modification  of  the  derived  data  object.  An  example 
of  such  a  situation  is  the  inclusion  of  derived  doc¬ 
uments  as  part  of  the  baselined  products  (see  Figure 
1.2. 2-1?.  Another  example  is  the  binding  of  certain 
classes  of  measurements  to  the  objects  they  measure. 

Ancestry  -  Most  data  objects  change  during  develop¬ 
ment  and  during  the  life  cycle  of  a  system.  In  many 
cases,  such  as  source  code  of  programs,  it  is  impor¬ 
tant  to  maintain  the  sequence  among  predecc  ssors. 

An  ancestry  relation  shall  be  provided  to  Ilow 
for  this. 

Version  -  The  version  macro  relation  refers  to  the 
mutation  of  a  system  or  system  release.  To  make 
this  view  workable,  micro  relations  should  exist 
which  identify  different  mutations  of  dat2  objects. 
For  example,  certain  programs  might  have  s jveral 
current  implementations  or  versions. 

Association  -  Certain  data  objects  can  be  related  in 
ways  thar  should  be  identified  explicitly.  For 
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example,  a  performance  model  might  have  been  developed 
for  an  alternative  system  design.  It  is  important 
to  bo  able  to  associate  this  model  with  the  appropri¬ 
ate  design. 

The  SEE  support  system  should  be  capable  of  monitoring 
the  data  objects  identified  as  having  micro  relationships. 

It  should  flag  reprocessing  when  one  data  object  within  a 
micro  relation  is  changed.  An  example  would  be  a  change  in 
a  design.  The  source  text  and  related  data  objects  would 
need  to  be  examined  and  possibly  adjusted. 
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Figure  1.2. 2-1:  Examples  of  Micro  Relations 

among  3aselined  Products 
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Support  System 


A  support  system  is  an  integrated  set  of  computer-based 
tools  supporting  all  activities  of  the  software  engineering 
process.  The  term  "integrated"  implies  a  system  where 
related  tools  have  simple,  compatible  interfaces  and  a 
consistent  structure  across  all  tools.  The  support  system 
contains  a  host  computer  and  peripheral  devices,  extensive 
software,  and  special  interface  equipment. 

The  support  system  requirements  presented  do  not  con¬ 
strain  the  choice  of  hardware  or  the  hardware  architecture. 
These  decisions  are  reserved  for  the  SEE  designers.  How¬ 
ever,  characteristics  of  I/O  devices,  target  system  inter¬ 
faces,  and  performance  constraints  are  given  which  restrict 
the  degree  of  latitude  in  hardware  selection.  Some  design 
constraints  are  defined  for  the  software  to  ensure  port¬ 
ability,  architectural  flexibility,  and  ease  of  change. 

The  support  system  (hardware  and  software)  must  be 
capable  of  handling  all  requirements  of  the  standard 
military  computers  used  by  the  Navy  as  well  as  future 
extensions  to  these  computers.  The  Navy  standard  com¬ 
puters  include  the  AN/UYK-43,  the  AN/UYK-44,  the  AN/UYS-1, 
the  AN/UYS-2,  the  AN/AYK-14 ,  the  AN/UYK-7 ,  the  AN/UYK-20, 
and  CP-642. 

The  support  system  must  have  a  mechanism  for  creating 
a  hierarchy  of  priorities  between  projects  and  between 
groups  of  users  (or  individuals)  within  projects.  Creating 
and  maintaining  the  priority  structure  is  the  responsibility 
of  the  management  function  controlling  the  critical  resources 
of  the  SEE. 

The  requirements  for  the  support  system  are  presented 
in  the  following  sections.  External  interfaces,  functional 
capabilities,  performance  constraints,  and  design  con¬ 
straints  are  described.  In  each  section,  an  introductory 
discussion  is  followed  by  itemized  requirements.  This 
format  was  chosen  to  improve  traceability  and  correctness 
analysis  for  future  implementations.  Most  of  the  itemized 
requirements  are  mandatory  and  are  marked  (R)  for  required. 
Optional  characteristics  of  the  support  system  are  tagged 
by  ( 0 ) . 


The  sections  under  Support  System  vary  widely  in  the 
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number  of  details  presented.  Because  of  the  importance  of 
the  command  language  as  the  primary  user  interface,  it  is 
given  detailed  treatment.  The  text  editor  and  the  report 
generator  are  also  given  special  emphasis  because  of  their 
general  applicability  across  activities.  Special  tools  are 
not  addressed  in  detail  due  to  the  treatment  given  them  in 
Part  I  of  this  document. 


2.1  External  Interfaces 


The  external  interfaces  to  the  support  system  include 
the  command  language,  I/O  devices,  and  interfaces  to  target 
systems.  The  command  language  is  important  because  it 
provides  the  only  means  to  access  SEE  resources,  and 
because  of  its  importance  an  entire  section  is  devoted  to 
it.  The  characteristics  of  the  I/O  devices  are  defined 
only  as  necessary  to  ensure  minimum  capability.  The  universe 
of  possible  interfaces  for  target  systems  is  given  with 
general  information  provided  for  special  devices  supporting 
siraulat ion/stimulation. 


2.1.1  Command  Language 


The  main  objective  of  the  SEE  command  language  (CL) 
is  to  support  software  professionals  by  augmenting  the 
creative,  intellectual  activities  and  automating  the  cleri¬ 
cal  activities.  The  CL  provides  access  to  SEE  resources 
by  SEE  users  -  managers,  designers,  programmers,  and 
testers.  The  CL  is  the  only  way  to  access  the  SEE  data 
base  and  support  system  functions.  It  must  be  consistent 
across  all  SEES. 

Because  of  the  wide  range  of  user  skills,  interests, 
and  use  patterns,  the  CL  must  be  human-engineered  for  both 
the  casual  and  the  sophisticated  user.  A  simple,  easy-to- 
learn  subset  must  be  available  at  one  end  of  the  spectrum. 

At  the  other  end,  the  CL  must  have  the  characteristics  of 
a  high-level  programming  language  for  the  user  who  must 
perform  complex  work  assignments  on  the  SEE. 

Such  a  diverse  3et  of  users,  accessing  the  SEE  resources 
and  representing  many  different  projects,  will  require  the 
CL  to  have  a  comprehensive  and  flexible  set  of  access  con- 
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trols.  These  controls  must  maintain  the  integrity  of  the 
SEE  resources  as  well  as  protect  the  integrity  of  a  project's 
or  user's  data.  These  controls  will  also  provide  management 
with  a  means  for  controlling  access  by  personnel  to  baselined 
products  and  SEE  resources. 

2. 1.1.1  Characteristics 


The  following  sections  list  the  required  characteristics 
of  the  SEE  command  language. 

2. 1.1. 1.1  Simplicity 


The  command  language  must  have  the  attribute  of  simpli¬ 
city. 

Users  ( E )  -  The  CL  must  support  a  range  of  users 

from  the  inexperienced,  casual  user  to  those  who 
use  the  SEE  for  complex  work  assignments.  For  the 
inexperienced  user,  the  CL  must  be  capable  of  use 
in  a  simple,  non-procedural ,  menu-driven  form. 

Prompting  (R)  -  When  used  interactively,  the  CL 

U!03f  have  a  prompting  mechanism  to  aid  the  inexpe¬ 
rienced  user;  prompting  must  be  explicitly  requested 
to  trigger  it. 

Defaults  (Ft)  -  The  CL  must  simplify  its  use  by 
including  defaults.  Parameter  defaults,  as  well  as 
the  ability  tc  customize  processing  sequences  should 
be  available. 


""he  commend  *  e  r.ge  v:e  must  also  have  power: 

r:.  1.  .  ae,»r  ill  ty  ...  -  The  CL  must  crevice  the  r.at.- 

uni  litres  of  i  “  ugh  *  .eve  1  programming  any  ..age  tor 
the  ~  ..  roust:  cured  user.  These  must  include  ccnci- 
r ion  and  loop  control  structures,  argument  run- 


t 
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dling,  variables,  string  manipulation,  named  proce¬ 
dures,  and  simple  but  powerful  I/O  instructions. 

Additional  Capability  (0)  -  Additional  programming 

capabilities  should  include  control  of  stored  proc¬ 
edures  via  parameters  and  simple  but  powerful 
arithmetic  expressions. 

Pipelining  Capability  (R)  -  The  CL  must  support 

the  concepts  of  "pipelining"  and  "redirection." 
Pipelining  defines  the  standard  output  of  one  pro¬ 
gram  as  the  standard  input  to  another  with  both  to 
be  run  in  sequence.  Redirection  defines  a  non-stand¬ 
ard  destination  for  output  upon  error  termination 
or  normal  completion  of  a  program. 

User  Extension  Exits  (R)  -  The  CL  must  be  extend- 

ible  through  user-defined  commands  like  functions 
in  a  high-level  programming  language. 


2. 1.1. 1.3  Integrity 


The  command  language  must  foster  reliability: 

Reliability  (R)  -  The  command  language  must  be 

designed  to  foster  creation  of  reliable  programs. 


2. 1.1. 1.4  Syntax 


The  syntax  of  the  command  language  must  have  certain 
attributes: 

Cons istent.  ( R )  -  The  CL  syntax  must  be  consistent 

from  its  high-level,  non-procedural  use,  down  to 
its  detailed  use  as  a  programming  language.  It 
must  also  be  consistent  across  all  SEES. 

ASCII  Character  Set  (R)  -  The  CL  must  use  the  ASCII 

character  set. 

Included  Comments  (R)  - 

to  be  included  in  CL  proce 


The  CL  must  allow  comments 
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English  Structure  (R)  -  The  CL  must  be  similar 

to  English  with  a  provision  for  abbreviated  forms 
for  the  experienced  user. 


2. 1.1. 1.5  Entry  Modes 


The  command  language  must  support  several  modes  of  data 
entry: 


Interactive  (R)  -  The  CL  must  be  available  in  an 

interactive  mode  with  prompting  support. 

Batch  Control  (R)  -  The  CL  must,  control  the  execu¬ 

tion  of  batch  jobs  in  the  SEE. 

Automatic  Invocation  (R)  -  A  CL  procedure  must  be 

capable  of  being  invoked  from  storage  as  though  it  had 
been  triggered  from  an  interactive  or  batch  mode. 


2. 1.1. 1.6  User  Aid 


The  command  language  must  provide  prompting  information: 

HELP  (R)  -  "Help*  must  be  available  to  the  inter¬ 

active  user  at  any  point  during  command  entry.  Help 
information  must  include  the  purpose,  use,  and  for¬ 
mat  of  commands  and  command  arguments.  The  Help 
function  must  be  designed  to  serve  as  an  immediate 
source  of  information  for  a  specific  CL  command  or 
function. 

Tutorial  (0)  -  Tutorial  support  should  also  be  pro¬ 

vided  to  educate  a  user  interactively  in  the  basic 
capabilities  of  the  SEE  and  the  CL. 

Abbreviated  Commands  (R)  -  Shortened  CL  commands 

and  names  must  be  provided  to  simplify  data  entry 
and  reduce  key  strokes. 
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2. 1.1. 1.7  Exception  Handling 


The  command  language  must  be  able  to  handle  a  number 
of  exception  conditions: 

Messages  ( R )  -  Informative  messages  in  English  must 

be  provided  when  a  CL-related  exception  condition  is 
detected.  The  messages  would  have  to  include  errors 
related  to  syntax  as  well  as  content. 

Specific  Identification  (R)  -  The  specific  command 

or  argument  causing  the  error  must  be  identified. 

Correction  (R)  -  Correction  of  the  error  must  be 

minimized  to  the  data  in  error. 

Abort  or  Redirection  (R)  -  The  ability  to  specify 

a  redirection  on  a  given  error  condition  must  be  pro¬ 
vided.  Also,  an  abort  on  the  error  condition  must 
be  permitted;  the  abort  must  be  graceful  and  the 
user  notified. 


2. 1.1. 2  Capabilities 


The  following  sections  list  the  SEE  capabilities  avail¬ 
able  through  the  command  language. 


2. 1.1. 2.1  Session/Job  Control 


The  command  language  must  control  both  sessions  and  jobs: 

Sessions  ( R)  -  An  interactive  session  between  a  user 
and  the  SEfi  must  be  started  and  ended  through  the  CL. 

Batch  (R)  -  Batch  jobs  must  be  started  and  controlled 

during  execution  through  the  CL. 
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English  Structure  (R)  -  The  CL  must  be  similar 

to  English  with  a  provision  for  abbreviated  forms 
for  the  experienced  user. 


2. 1.1. 1.5  Entry  Modes 


The  command  language  must  support  several  modes  of  data 
entry: 


Interactive  (R)  -  The  CL  must  be  available  in  an 

interactive  mode  with  prompting  support. 

Batch  Control  (R)  -  The  CL  must,  control  the  execu¬ 

tion  of  batch  jobs  in  the  SEE. 

Automatic  Invocation  (R)  -  A  CL  procedure  must  be 

capable  of  being  invoiced  from  storage  as  though  it  had 
been  triggered  from  an  interactive  or  batch  mode. 


2. 1.1. 1.6  User  Aid 


The  command  language  must  provide  prompting  information: 

HELP  (R)  -  "Help"  must  be  available  to  the  inter¬ 

active  user  at  any  point  during  command  entry.  Help 
information  must  include  the  purpose,  use,  and  for¬ 
mat  of  commands  and  command  arguments.  The  Help 
function  must  be  designed  to  serve  as  an  immediate 
source  of  information  for  a  specific  CL  command  or 
function. 

Tutorial  (0)  -  Tutorial  support  should  also  be  pro¬ 

vided  to  educate  a  user  interactively  in  the  basic 
capabilities  of  the  SEE  and  the  CL. 

Abbreviated  Commands  (R)  -  Shortened  CL  commands 

and  names  must  be  provided  to  simplify  data  entry 
and  reduce  Icey  strokes. 
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2. 1.1. 1.7  Exception  Handling 


The  command  language  must  be  <ble  to  handle  a  number 
of  exception  conditions: 

Messages  (R)  -  Informative  messages  in  English  must 

oe  provided  when  a  CL-related  exception  condition  is 
detected.  The  messages  would  have  to  include  errors 
related  to  syntax  as  well  as  content. 

Specific  Identification  (R)  -  The  specific  command 

or  argument  causing  the  error  must  be  identified. 

Correction  ( R )  -  Correction  of  the  error  must  be 

minimized  to  the  data  in  error. 

Abort  or  Redirection  (Rj  -  The  ability  to  specify 
a  redirection  on  a  given  error  condition  must  be  pro¬ 
vided.  Also,  an  abort  on  the  error  condition  must 
be  permitted;  the  abort  must  be  graceful  and  the 
user  notified. 


2. 1.1.2  Capabilities 


The  following  sections  list  the  SEE  capabilities  avail¬ 
able  through  the  command  language. 


2. 1.1. 2.1  Session/Job  Control 


The  command  language  must  control  both  sessions  and  jobs: 

Sessions  (R)  -  An  interactive  session  between  a  user 

and  the  5£2  must  be  started  and  ended  through  the  CL. 

Batch  (R)  -  Batch  jobs  must  be  started  and  controlled 

during  execution  through  the  CL. 
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2. 1.1. 2. 2  Access  Control 


The  command  language  must  control  user  access  to  SEE 
resources: 

Access  Control  to  SEE  (R)  -  An  access  control 
mechanism  must  be  provided  to  protect  key  SEE 
resources.  These  resources  must  include  executing 
SEE  programs,  SEE  programs  resident  on  the  data 
base,  and  any  other  data  in  the  SEE  data  base  which 
is  vital  to  the  correct  operation  of  the  SEE. 

Access  Control  by  Project  (R)  -  The  access  control 

mechanism  must  support  certain  management  functions. 

It  must  be  possible  to  restrict  the  access  of  project 
personnel  to  various  classes  of  project  data.  The 
baselined  products,  in  particular,  must  be  completely 
under  the  control  of  configuration  management. 

Data  Protection  (R)  -  Individuals  must  be  able  to 

define  data  in  their  work  space  as  private.  This 
must  not  preclude  management  inspection  of  work- 
in-process. 

Control  of  Security  Classifications  (O)  -  The  access 

mechanism  should  provide  for  security  classifications 
for  designated  portions  of  the  SEE  data  base. 


2. 1.1. 2. 3  Data  Base  Manipulation 


The  command  language  must  control  the  manipulation  of 
data  objects: 

Data  Base  Creation  ( R )  -  It  must  be  possible  to 

create  new  data  base  objects  through  the  CL  facilities. 

Data  Base  Utilities  (R)  -  It  must  be  possible  to 

retrieve,  copy,  rerame,  store  and  delete  data  base 
mb jects  through  the  CL. 

Authorized  Data  Base  Commands  VK)  -  Commands  for 
data  base  manipulation  which  the  user  is  authorized 
to  oerfovm  must  be  available  to  the  user. 
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2. 1.1. 2. 4  Program  Invocation 


The  command  language  must  control  the  use  of  programs: 

Program  Invocation  (R)  -  The  CL  must  be  capable  of 

invoking  SEE  programs  or  any  other  program  in  the 
SEE  data  base. 

Interactive/Background  Interface  (R)  -  The  CL  must 

be  capable  of  creating  background  Jobs  from  an  inter¬ 
active  session  and  report  to  the  user  the  status  or 
results  of  the  job  and  the  disposition  of  the  data. 


2.1.2  Characteristics  of  SEE  Hardware 


SEE's  are  very  sophisticated  systems.  The  importance 
of  its  hardware  should  not  be  underestimated  as  it  has  a 
significant  impact  on  the  quality  and  performance  of  the 
SEE  to  the  user.  The  SEE  must  support  many  users  with 
widely  differing  applications  and  requirements.  It  needs 
good,  reliable  hardware  to  fulfill  its  mission. 

The  SEE's  processing  power  will  not  be  discussed.  The 
hardware  it  needs  to  support  its  users  directly  will  be 
discussed  but  in  terms  of  general  characteristics.  Detailed 
specifications  for  hardware  will  not  be  presented.  The  SEE 
hardware  needed  to  support  the  user  directly  is  listed: 

Interactive  Text  Display  (R)  -  This  video  device 

must  support  the  display  and  entry  of  data  inter¬ 
actively.  It  must  display  at  least  one  page  of 
alphanumeric  data.  It  must  be  easily  read  and 
designed  for  minimum  fatigue  with  continual  use. 

It  must  have  local  memory  equivalent  to  two  full 
pages.  It  must  allow  remote  correction  to  the  SEE 
via  a  synchronous  protocol.  It  must  provide  for 
upper  and  lower  case,  have  a  clearly  visible  cursor, 
support  the  128  character  ASCII  set,  contain  special 
function  keys,  and  allow  selection  of  character  or 
fields  on  the  display. 

Bulk  Printer  (R)  -  This  device  must  be  designed 

for  high  speed  printing  of  entire  alphanumeric  text 


'■  oijo rr  Sv:' -.era:  Pxre:  :i.i .  ’  ",  .  o -e.  as  hjae 
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vo  oispidv  a  .'.a  :.ar..'i;ld’.e  vector  qr  tphics .  The 
display  wi.i  rats  a  controllable  cursor  c  vpat  la  o  f 
addressing  a  sina.e  display  picture  element.  ;p.xei !  . 

Sulk  Text _ In  try  ( r, ;  -  mis  device  should  scan 

printed  alphanumeric  text  and  electronically  encode 
them  automatical Iv.  It  should  be  capable  of  reading 
multiple  fonts. 

Bulk  Graphics  Entry  (0)  -  This  device  should  scan 

line  graphics  and  electronical ly  encode  them  auto¬ 
mat  icaily . 

Quality  Printer  yR)  -  Tn  i  s  device  must  create 
printed  output  of  publication  quality  -i.e.,  camera- 
ready  copy).  It  must  support  .Multiple  tents  and 
simple  line  graphics. 

Graphics  Printer  (O)  -  This  device  should  create 

complex,  high  quality  graphics  of  publication  quality. 

Individual  Workstations  <C)  -  Individual  worksta- 

tions ,  SasecT  on  microprocessor  technology,  might  be 
provided  for  users.  These  devices  should  be  able  to 
hold  portions  of  the  SEE  data  base  temporarily,  and 
to  operate  in  either  stand-alone  or  attached  modes. 
They  should  provide  the  equivalent  I/O  capability  of 
an  interactive  text  device  with  printed  output  and, 
possibly,  interactive  graphics. 

The  SEE  computers  must  support,  either  directly  or 
via  I/O  controllers  and  communication  controllers,  the  fol¬ 
lowing  physical  interfaces:  Electronic  Industries  Association 
(SIA)  RS- ^  3  2C •  RS-422/42C,  X.21,  IEEE  489,  and  optionally 
X.25,  nil  I/O  devices  snail  adhere  to  at  least  one  of 
tne  required  three  physical  ..nlerface  standards.  For  par¬ 
allel  transfer,  the  American  Standard  Code  for  Information 
Interchange  ASCII  i  - -bit-pius-parity  cede  must  be  used. 
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Pu rtose 


Operation  and 
control  of  SEE 
physical  resources 

Development  and 

continuing  adaptation 
of  ECS  software 


Analysis  of  measurement 
and  archive  data  to 
improve  software 
engineering  process. 


I/O  Devices 


Interactive  Text 
Display  (R) 
Bulk  Printer  (R) 


Interactive  Text 
Display  (R) 
Interactive 
Graphics  (R) 

Bulk  Text  Entry  (0) 
Bulk  Graphics 
Entry  (0) 

Bulk  Printer  (R) 
Quality  Printer  (R) 
Graphics  Printer  (R) 
Individual  Work¬ 
stations  (0) 


Same  as  for 

project  personnel 


Figure  2. 1.2-1:  SEE  User  Classes 
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2.1.3  Target  System  Interfaces 


The  SEE  must  support  interfaces  to  ECS  target  system 
equipment  mainly  for  supporting  software  tests  and  ECS 
system  tests.  Various  interfaces  must  be  provided  to  the 
target  systems  on  the  assumption  that  the  SEE  provides  for 
down-line  loading  of  the  ECS  software,  environment  simula¬ 
tion,  data  extraction  and  reduction,  and  performance  moni¬ 
toring  in  support  of  tests. 

The  target  system  interfaces  can  be  divided  into  two 
classes:  computer-to-computer  and  sim/stim.  The  first 

class  addresses  computer-to-computer  links  between  SEE 
computers  and  target  computers.  The  second  class  addresses 
interfaces  for  stimulation  of  target  system  equipment. 

The  computer-to-computer  interface  will  link  a  SEE 
computer  to  a  target  system  computer  such  that  each  appears 
to  be  an  I/O  device  to  the  other.  The  standard  Navy  mili¬ 
tary  computers  supported  include  the  AN/UYK-43,  AN/UYK-44, 
AN/UYS-1,  AN/UYS-2,  AN/AYK-14,  AN/UYK-7 ,  AN/OYK-20,  and 
CP-642. 

The  stimulation  interfaces  for  target  system  equipment 
will  be  supported  through  one  or  more  interface  controllers 
with  the  following  characteristics. 

Modular  Interface  -  The  interface  equipment  will 
be  modularly  constructed  and  programmable;  this  will 
simplify  changes  to  handle  the  special  interface 
requirements  of  new  target  system  equipment. 

Signal  Conversion  -  The  interface  will  provide 
for  analog/digital,  digital/synchro,  and  other  con¬ 
versions  to  support  special  target  system  equipment. 

Format  Conversion  -  The  device  will  be  capable  of 
format  conversions  lender  program  control. 

2.2  Functional  Capability 


This  section  describes  the  functions  of  the  support  sys¬ 
tem.  It  is  only  concerned  witn  the  externally  accessiole 


-  -  t  .  ^  ;  v  '  . .  .  -  L  *  -  V  i  .Id  Tc  i  '3  -  ‘ 

..  J.I..  ^  .  ri  i.t  t  .'l  Jfc  idU'.C  wl  C  Ojf  tW^L  ;- 


. .  »  .  ..  • . '  *  .1  ^  _  ■.  . .  j  y  *j  -  *3iTi  -  u  n  c  “ 

-4.. .4  -•  ....,44c  ..  .  ......  • — ... j  functions 

control  :.iu  ...-jout  --es  .,L  . .  a  support  s>  s '.  s.n ,  coordination 
a mono  multiple  interact  11 j  users ,  and  the  integrity  of  tne 
data  base .  The  software  .gtneering  1 -nations  include 
data  base  manipulations  ..  .d  processes  directly  supporting 
the  software  eng  1  nee r  1 .. c  »..tivities. 

2.2.1  System  Eunctic..s 


The  jupuott  system  must  provide  interactive  and  batch 
pi  or easing  in  an  environment  with  many  users.  It  wiil 
to. tool  -ill  use  of  system  resources,  support  local  or  remote 
users  or.  a  high-priority  oasis,  and  support  oatch  processing 
on  a  low-priority  basis. 

2. 2. 1.1  Multi-User  Interactive  Support 


The  system  must  support  multiple  users  in  an  interactive 

environment; 

The  system  must  support  mul¬ 
ing  SEE  resources  in  an  interactive 
mode;  users  may  be  either  local  or  remote. 

Resource  Sharing  (R)  -  The  system  must  allow  shar¬ 

ing  of  SEE  resources;  contention  for  limited  resources 
shall  be  efficiently  coordinated. 

Multi-Level  Security  (H)  -  In  the  implementation  of 

any  of  the  system  services  for  a  SEE,  no  design 
decisions  should  be  made  that  would  preclude  the 
implementation  or  retrofit  of  multi-level  security 
operations. 


Multiple  Users  (R? 
tiple  users  access 
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2. 2. 1.2  Background  Processing 


The  system  must  provide  a  for eg round/b^ok ground  envi¬ 
ronment: 

Foreqround/Background  (R)  -  The  system  must  have 

both  a  foreground  and  a  background  mode  thus  taking 
advantage  of  the  inherent  nature  of  interactive 
processing.  The  system  will  allocate  most  of  its 
priority  resources  to  service  the  foreground,  thus 
providing  good  response  for  short,  interactive 
processes.  Background  processing  must  be  provided 
to  make  full  use  of  system  resources.  Stacked 
batch  jobs  will  be  started  automatically  by  back¬ 
ground  as  resources  become  available.  (Batch  jobs 
are  sequential  in  nature  and  require  no  manual 
intervention. )  Batch  jobs  can  also  be  run  in  fore¬ 
ground. 

Batch  Jobs  (R)  -  It  must  be  possible  to  enter  jobs 
on  a  queue  £rom  an  interactive  session  without 
terminating  the  session.  Notification  of  the  job 
status,  and  access  to  the  results  during  the  inter¬ 
active  session  must  be  possible. 


2. 2. 1.3  Data  Base  Management 


The  system  will  provide  full  data  base  support: 

DBMS  (R)  -  The  data  base  management  function  ( DBMS ) 

must  allow  creation,  retrieval,  and  modification  of 
data  identified  in  Section  II. 1.1,  and  must  include 
data  relations. 

Logical  Views  (R)  -  The  data  base  management  func¬ 

tion  must  support  logical  views  of  data  base  objects 
as  identified  in  Section  II. 1.2. 

High-Level  Functions  (R)  -  The  data  base  management 

function  must  allow  manipulation  of  the  data  base 
through  high-level  function  calls  whicn  require  no 
knowledge  of  the  physical  organization  or  location 
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n  to  relations 
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base  management  s/s- 
ana  tie  maintenance  of 
data  ob j ects. 

2.2. 

1.4  Pipelining  and 

Red i rect ion 

The  system  must  sv 

pport  pipelining 

ar.d  redirection: 

Pipelining  (R)  -  Pipelining  permits  several  pn- 

grams  to  6e  run  in  succession  without  operator 
intervention.  The  output  of  one  program  can  be 
designated  as  the  nput  to  one  or  more  succeeding 
programs  via  temporary  files  or  buffers. 

Redirection  ( R )  -  Redirection  of  output  due  to 

abnormal  error  conditions  or  termination  of  a  ;ob 
must  be  supported. 


2. 2. 1.5  Operational  Control 


The  system  must  provide  the  system  operator  with  a 
full  set  of  controls: 

Control  of  Support  System  (R)  -  Control  must  be 

via  the  on-line  operator's  console.  The  operator 
must  have  adequate  facilities  and  flexibility  to 
control  how,  when,  and  to  what  extent,  system  opera¬ 
tions  are  performed.  Functions  such  as  system 
startup,  monitoring  of  operations,  and  system  termi¬ 
nation  must  be  available.  All  system  functions 
must  be  capable  of  operation  in  full,  partial,  or 
degraded  modes. 

System  Configuration  (R)  -  The  system  operator 

must  be  able  to  configure  the  system  during  startup 
or  during  operation.  Reconfiguration  shall  be 
non-disruptive  to  system  users.  (Configuration 
changes  can  be  made  for  a  number  of  reasons  such  as 
a  component  failure,  the  need  for  preventive  mainte¬ 
nance,  or  an  intermittent  error  condition. ) 

Backup  and  Restore  (R) 


The  operator  must  have  a 
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occurring  since  the  last  nackup. 

Short-term  and  long-term  backup  sLoraye  must  be 
available,  the  first  for  active  data  and  the  second 
for  inactive  data.  The  operator  must  be  able  to 
restore  active  data  quickly  and  inactive  data  simply 
and  directly.  Restoring  inactive  data  will  require 
search  arguments  (such  as  project  identifier)  to 
locate  the  data  before  it  is  restored. 

System  Degradation  (R^  -  The  support  system  must 

be  able  to  degrade  gracefully  under  increasing 
levels  of  system  errors.  System  users  must  be 
provided  either  automatic  or • semi-automatic  save 
procedures  so  that  work-in-process  can  be  saved 
before  a  forced  or  unforced  sign-off.  The  system 
must  log  the  status  for  later  analysis  at  the  point 
of  degradation  or  crash. 

System  Recovery  (R)  -  The  operator  must  be  able  to 
restore  the  system  automatically,  either  fully  or 
partially,  after  system  degradation  or  a  system 
crash.  The  operator  also  must  be  able  to  determine 
the  system  configuration,  and  the  status  of  the 
background  job  stream,  at  the  time  of  the  degradation 
or  system  crash. 

System  Statistics  (0)  -  The  support  system  should 

keep  adequate  statistics  on  what  resources  have 
been  used  and  by  whom  for  analysis,  cost  accounting, 
and  billing. 

2. 2. 1.6  Remote  Access 


The  system  must  support  remote  users: 

Remote  Users  (R)  -  Users  wr.c  are  remote  geograph¬ 

ically  must  or>  able  to  access  SEE  resources  over 
;e  loDommunicai Lons  oaths  tor  either  1 nt erect  tv-  v. 
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oatch  operations. 

Remote  User  Interface  (R)  -  The  interface  must  be 

the  same  for  remote  users  and  local  users. 


2. 2. 1.7  Access  and  Resource  Control 


The  system  must  provide  certain  control  functions: 

Access  Control  (R)  -  A  system  mechanism  must  be 

provided  to  control  access  to  the  SEE  via  a  system- 
wide  list  of  authorized  users.  Access  control  must 
also  include  password  protection. 

Resource  Control  (R)  -  A  system  mechanism  must  be 

provided  to  control  access  of  authorized  users  to 
SEE  resources.  Resource  control  must  also  include 
password  protection. 

Data  Protection  (R)  -  A  system  mechanism  must  be 

provided  to  permit  data  to  be  protected  as  read-only 
data,  read/write  data,  or  update  data  (read  implied). 
It  must  be  possible  to  protect  data  (files, 
records  or  fields)  via  a  password  mechanism.  Such 
protection  shall  not  limit  management  control. 

Security  Protection  (R)  -  A  system  mechanism  must 

be  provided  for  protecting  all  or  part  of  a  data 
base  containing  classified  information.  Such  a 
mechanism  must  also  be  capable  of  protecting  project 
information  separately.  (Encryption  is  one  technique 
for  protecting  information  either  partially  or  fully. 
Different  cryptographic  keys  can  be  used  to  protect 
information  from  different  projects  or  different 
users  or  both ) . 


2. 2. 1.8  Utilities 


The  system  must  provide  a  variety  of  general-use 
functions : 

SEE  Data  Base  Transport  (R) 


he  SEE  must  provide 
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Full-Screen  Editing  (R)  -  The  text  editor  must  sup¬ 

port  full-screen  editing  on  a  full  page  of  text  as 
displayed  on  the  interactive  text  display. 

Buffering  Capability  (R)  -  Edit  operations  must  be 

performed  on  text  in  an  edit  buffer  and  will  have 
no  effect  on  the  data  base  copy  until  a  store  opera¬ 
tion  is  explicitly  given.  Text  in  the  edit  buffer 
will  be  viewed  on  the  display  through  vertical  and 
horizontal  scrolling  commands.  It  must  be  possible 
to  merge  separate  text  objects  in  the  edit  buffer. 

Split-Screen  Mode  (0)  -  Multiple  edit  buffers 

should  be  assigned  to  a  single  terminal  user.  It 
should  be  possible  to  view  these  through  split 
screen  operations;  each  edit  buffer  would  be  acted 
upon  as  though  it  were  supporting  a  single  terminal. 

Text  Composition  Mode  (R)  -  The  text  editor  must 

support  a  text  composition  mode  with  the  following 
minimum  operations: 

Continuous  typing  with  word  wrap, 

-  Automatic  reflow  of  text  when 

column  boundaries  are  changed,  and 

Insert  and  delete  operations  which  exceed  single 
line  boundaries. 

Character  String  Substitution  (R)  -  The  system 

must  provide  for  the  substitution  of  one  character 
string  for  another,  wherever  it  appears  within  a 
designated  block  of  text,  or  within  the  edit  buffer 
in  its  entirety. 

Tao  Control  (R)  -  It  must  be  possible  to  define 

taos  on  the  screen  to  simplify  cursor  movement. 

Cursor  Positioning  (R)  -  Control  of  the  cursor  posi¬ 

tioning  from  the  terminal  must  permit  up,  down,  left, 
and  right  movement,  and  commands  for  "home." 

Edit  Command  Sequences  (0)  -  The  system  should  per- 

mit  named  sequences  of  id  1 1  commands  to  be  stored. 
These  sequences  should  be  invoked  to  operate  on 


Pace  II 
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data  placed  in  tne  edit  ouffer. 

Consistent  Syntax  (R)  -  The  syntax  and  convert  .  ns. 

of  tne  edit  commands  must  j«  consistent  with  the 

command  Language  syntax. 

Structured  Progamming  (0)  -  The  editor  should 

support  structured  programming  techniques  by  auto¬ 
matically  indenting  PDL  and  code,  according  to  the 
nested  use  of  control  structures,  and  automatically 
underscoring  PDL  keywords. 

Highlighting  (0)  -  The  editor  should  use  highlight¬ 

ing  (or  reverse  highlighting)  to  emphasize  text 
elements  which  are  subjects  of  certain  operations 
such  as  an  error  condition. 

Line-Or iented  Editing _ (R]_  -  The  text  editor  must 

provide  certain  line-oriented  operations:  line 
numbers  for  use  in  edit  operations;  a  "find"  command 
to  locate  a  line  number  or  character  string;  commands 
to  insert,  delete,  move,  or  copy  lines  or  blocks  of 
lines;  commands  to  shift  lines  or  blocks  of  lines 
left  or  right;  and  commands  to  insert,  delete,  or 
replace  characters  within  a  line. 


2. 2. 2. 1.2  Document  Generation 


The  system  must  provide  a  general  purpose  report  gen¬ 
erator: 


Formatting  (R)  -  The  document  generation  function 

must  format  text  for  viewing  on  an  interactive 
text  device  or  for  printing  or  plotting  graphic'^---* 
material. 


Photocomposition  (0)  -  Text  should  oe  formatted 

for  photocomposition  equipment  (or  equivalent). 

Input  for  Document  Genera t icr  ; R )  -  The  input 

Function  must  permit:  text,  symbolic  codes  repre¬ 
senting  strings  to  be  substituted  m  the  text  before 
printing,  embedded  commands  which  control  text 
format,  and  macro  commands.  (Macro  commands  are 
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user-generated  super  commands  consisting  of  groups 
of  embedded  commands.) 

Page  Layout  (R)  -  Certain  page  layout  functions 

must  be  provided : 

line  formatting  including  concatenat ion ,  center¬ 
ing  and  right  and  left  justification; 

Definition  of  blank  lines  for  spacing; 

Definition  of  paragraph  style  and  spacing; 

Provision  for  multiple  fonts  designated  by  running 
headings  or  tekt  blocks; 

Column  definition; 

Definition  of  top,  bottom,  left,  and  right 
margins; 

Provision  for  running  headings  and  footings,  and 
automatic  page  numbering;  and 

Definition  of  tab  settings  for  tabular  informa¬ 
tion. 

Text  Composition  -  Certain  text  composition  func- 
tions  must  be  provided : 

Automatic  flowing  of  text  into  columns  for  proper 
width,  length,  and  layout  specifications; 

Provision  for  inseparable  text; 

Hyphenation; 

Provisions  for  text  blocks  which  must  start  at 
the  top  of  a  page  or  the  top  of  a  column. 

Headings  -  Up  to  seven  levels  of  heading  must  be 
allowed,  each  with  unique  formatting  specifications. 

Taple  of  Contents  -  Automatic  generation  of  the 
taole  of  contents  with  page  numbering  must  be  pro- 
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video.  Optionally,  manual  placement  shall  be  allowed. 

Footnotes  -  Floating  footnotes  must  be  placed  at 
the  bottom  of  the  appropriate  pages  or  optional!-/ 
placed  at  the  back  of  the  document. 

i 

Revision  Indicators  -  Provisions  must  oe  made  tor  , 

indicating  revisions  on  each  page.  .  1 

Dictionary  -  Provisions  must  be  made  to  pro. 

Junction  "tor  checking  spelling  if  standard  Sriuim-  J 

as  well  as  project-specific  terms,  acronyms  and  J 

mnemonics.  \ 

Inde_x  and  Cross-Reference  -  Provisions  must  ;>■  , 

made  Tor  automatic  generation  of  terms  f^aggec  ....  j 

nr  index  or  cross-reference .  ' 

Standard  bj/r.t.ix  -  The  syntax  and  co-  vent  ions  used  ; 

for  tST  interaction  with  is  tool  must  be-  consistent  ; 

with  those  defined  for  the  CL.  , 


2.2. 2.1.3  Tool  null ding  Aids 

The  system  rust  encourage  the  creation  and  use  of 

tools  cor . ruche..;  from  too 1  atoms  (tool  fragments).  Tools 

will  ali.’.-.;  s  be  evolving  as  old  tools  are  extended,  new 
tools  are  created,  and  single-use  tools  are  quickly  con¬ 
structed  and  discarded.  The  tool  building  mechanism  should 
be  simple,-  flexible  and  efficient  to  use. 

Tool  Atoms  )  -  The  LFF  must  prt"’  de  j  set  of. 

t i~  ru  i  16  '  ng  blocks  <  tool  c.hnrr.3  ’  .  These  atoms  a  lo:.t 
r f c v «r  no  useful  tasks  cut  in  ccr  :::n,u  i.v  w  : t h  c-  t\  r 
rc-ms  can  create  useful  sot  f- are  enc  :  v-e:  ■  ng  mo 
T‘  >  mini  mum  tool  set  must  support  ran  a,"«:  r. 
mb  t -.ran'5  it  on-  "  •  ons . 
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Tool  atoms  will  be  designed  for,  and  mostly  used  by, 
the  software  engineering  specialists.  This  aporoacr. 
limits  the  general  application  of  tool  atoms  but 
also  simplifies  the  design  and  interface  structure 
since  tool  atoms  need  not  be  designed  for  universal 
use.  This  does  not  preclude  the  use  of  tool  atoms 
by  application  programmers  (and  others)  but  they 
must  ne  willing  to  learn  how  to  design  and  construct 
tools  from  atoms. 

Compining  Atoms  (R)  Tool  atoms  must  be  designed 
for  combination  in  pipelining  fashion,  or  as  called 
procedures  within  a  command  language  program. 

Index  (R)  -  An  index  of  abstracts  describing  avail 

able  tool  atoms  must  be  provided.  This  index  would 
be  used  during  tool  design  and  implementation. 


2. 2. 2.2  Activity-Specific  Tools 


Requirements  for  activity-specific  tools  are  derived 
from  the  discussions  of  activities  in  Part  I.  These  dis¬ 
cussions  outlined  the  methodologies  which  lead  to  the  need 
for  automated  tools.  This  progression  from  activity  to 
methodology  to  tool  is  summarized  in  Figure  2. 2. 2. 2-1. 
Descriptions  of  each  tool  can  be  found  in  Part  I  under  the 
appropriate  activity  description. 

Only  a  small  set  of  the  tools  is  mandatory  and  marked 
(R)  for  required.  These  are  the  tools  required  for  the 
formal  recording  of  baselined  products  plus  some  frequently 
used  analysis  tools.  All  other  tools  are  marked  as  optiona 
(0).  This  approach  is  in  line  with  the  strategy  of  rigor¬ 
ously  defining  the  baseline  product  methodologies,  but 
allowing  the  professional  freedom  of  choice  in  the  support¬ 
ing  methodologies  and  tools  which  augment  analysis  and 
creativity. 

Each  of  the  tools  in  Figure  2. 2. 2. 2-1  to  2. 2. 2. 2. 6 
should  possess  certain  basic  characteristics  to  assure 
integration  within  the  SEE  support  system.  These  charac¬ 
teristics  are: 


Standard  Capabilities  (R' 


Each  activity-specific 
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fool  mus 1  use  the  standard  cacao.  l.ties  jf  r.-e  SEE 
operating  system  and  data  base  manager. 

Consistent  Syntax:  dandatory  Tools  -  Each 

activity-specific  tool  ~h’C:  has  beer,  identified 
is  mandatory ,  and  which  includes  a  comm  one  .  »ngu..- 
:m.  r»t  oe  implemented  sue  >  that  . s  comma m  icc^i- 
synf  i .<  and  c  inventions  ace  coi< si:.  tent  wit r.  .:n-  ic  y 
command  language  across  all  SF.Cs. 


_T on s_i st e c.t  Sy n tax  ;  Got  lonal 
possible,  optional  activity 
include  a  command  language 
that  their  command  language 
are  consistent  with  tre  SEE 

High-level  Language _ (  R ) 

tool  must  be  implemented  m 
to  ensure  portability. 


Tools  -  h'- uic  er 

-specie  ic  dels  . cn 
snould  ce  implemented  so 
syntax  and  c  nvetota 
command  language. 

Each  activity-specific 
a  high-level  language 


Pipelining  (R)  -  Certain  groups  of  act iv i ty- 

specific  tools  must  be  implemented  in  such  a  way 
that  pipelining  is  possible  among  them.  The  sets 
of  such  tools  that  must  have  pipelining  capaoiiity 
within  the  set  are  shown  in  Figure  2.2.2-2-T.  The 
arrows  -*>  indicate  the  sequence  taken  by  pipelining, 
while  the  braces  [  ]  define  the  set  of  tools  in  the 
pipelining  sequence. 


Instrumentation  (R)  -  Activity  specific-tools  must 

be  instrumented  to  generate  the  measurements  data 
described  in  II. 1.1. 3, 
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Activity  Methodology  Tool 

Language  Analyzer  (R) 

Report  Generator  (R) 

Consistency /Completeness 
Analyzer  (O) 

Modeling  Tool  (0) 

Demonstration 


Figure  2. 2. 2. 2-2:  Flow  of  Specification:  Activity 

to  Methodology  to  Tool 
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•’ode  ling  Tool  o': 


\  '  Data  Flow  Anal  vs  is  v 
\  \  \  ‘  \ 

\\  \  Data  Structure 
\  \  Transformation 

\  '  Graphic  Decomposition 
\  Techniques  ^ 


\  isuii 

'  Graphic 


Graphic  Control 
Techniques 


Graphic  Packages (0) 


Figure  2. 2. 2. 2-3:  Flow  of  Design:  Activity 

to  Methodology  to  Tool 
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Activity 


Methodology 


Tool 


Instrumented 
Analysis  - 


Assembler  (R) 

Compiler  (R) 

Preprocessor  (R) 

Pretty  Printer  (R) 

Design  Extractor (0) 

Analysis  Tool  (0) 

Linkers/loader  (R) 

Host-targeted 
Compiler  (0) 

Simulator(O) 

Debugger (0) 

System  Builder(O) 

Ada  Run-time  (R) 
Support 

Data  Extraction/ 
Reduct ion (0 ) 


Figure  2. 2. 2. 2-4:  Flow  of  Implementation:  Activity 

to  Methodology  to  Tool 
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Activity 


Methodoloc 


Tool 


Performance  Model(O) 
Prototyping  Aid(O) 

Consistency  Analyzer(O) 

Standards  Checker(O) 

Assertion  Analyzer(O) 

Symbolic  Execution  (0) 

Theorem  Prover(O) 

Test  Harness  (R) 

Test  Data  Generator  (R) 
Host-targeted  Compiler  (0) 
Hardware  Simulator(O) 

Test  Results  Comparator  ( R ) 
Environment  Simulator  (R) 

Performance  Monitor  (R) 

Data  Extraction/Reduction  (R) 
Scenario  Generator  (R) 

Black  Box  Test  Generator  (R) 

Reliability  Model (0) 


Figure  2.2. 2. 2-5:  Flow  of  Correctness  Analysis: 

Activity  to  Methodology  to  Tool 
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Activity 


Methodology 


Tool 


Management 


Estimation 


Precedence 

Network 


Resource  Estimation 
Model  (0) 

Automated  Precedence 
Network  (0) 

Schedule  Generator  (0) 


Change  Control — Change  Request  Tracker  ( R 

^  Automated  WBS  (0) 

Other  Planning^—  Resource  Scheduling 
\  Aid  (0) 

'  Report  Generator  (K) 

Programming  Teams 


Figure  2 . 2 . 2 . 2-6 : 


Flow  of  Management:  Activity 
to  Methodology  to  Tool 
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Requirements  Analysis: 

[Semantics  language  processor 

=*>  semantics  information  browse 
**>  semantics  analyzer 
=*>  report  generator] 


Specification: 

[Language  analyzer 

==>  consistency/completeness  analyzer 
=■*>  report  generator] 


Design: 

[ PDL  syntax  analyzer 
*■>  PDL  interpreter 
=*=»>  report  generator] 


Implementation: 

[Preprocessor 

*=*>  assembler  or  compiler 
«>  pretty  printer 
«>  design  extractor 
=*>  analysis  tools 
=*=>  compiler  or  assembler 
*»>  linker/loader 
*=»>  hardware  simulator 
=»>  debugger 

=»=>  data  extraction/reduction] 


Correctness  Analysis: 

[Test  data  generator 
»»>  test  harness 
»*>  hardware  simulator] 


Figure  2 . 2 . 2 . 2-C : 


Pipelining  for  Activity-Specific  Tools 
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2-2.2. 3  Application  Paradigms 


Many  software  design  and  implementation  problems  are 
well  understood  and  continually  recur  in  new  systems. 
Unfortunately,  the  designs  and  implementations  of  previous 
systems  are  not  captured  and  reused  in  succeeding  systems. 
Thus,  a  significant  opportunity  for  productivity  improvement 
is  lost. 

Two  features  of  the  SEE  are  described  to  address  this 
serious  problem:  reusable  components  and  program  skeletons. 
Reusable  system  components  are  commonly  recurring  components 
which  can  be  designed  and  implemented  once  with  appropriate 
parameters  for  tailoring  to  different  applications;  these 
components  might  include  firmware.  Program  skeletons  pro¬ 
vide  the  structure  into  which  application-specific  modules 
can  be  incorporated. 


2. 2. 2. 3.1  Reusable  Components 


The  system  must  support  and  encourage  the  creation 
and  maintenance  of  reusable  components: 

Interface  Standard  (R)  -  A  rigorous  interface 

standard  must  be  provided  for  all  candidate  reusable 
components;  it  would  govern  design,  implementation, 
and  documentation. 

Library  (R)  -  A  library  of  reusable  components 

must  evolve  for  use  by  all  development  activities. 

Index  (R)  -  An  index  of  reusable  components  includ¬ 

ing  summary  descriptions  and  specifications,  must 
be  provided  to  help  the  designer  locate  appropriate 
components. 


2. 2. 2. 3. 2  Program  Skeletons 


The  system  must  also  support  program  skeletons: 


Design  Standard  (R) 


A  rigorous  design  standard 
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must  be  provided  for  any  major  software  system  or 

subsystem  to  be  implemented  as  a  skeleton. 

Skeleton  Library  {A]  -  A  sparse  library  of  sub¬ 

system  or  system' skeletons  must  be  provided  for  use 
in  new  development  activities. 

Supporting  Tools  (R?  -  A  set  of  supporting  tools 

must  be  be  implemented  to  aid  in  the  expansion  of 
the  skeletons. 

2.3  Performance  Guidelines 


The  performance  of  a  SEE  plays  an  important  role  in 
•  ■petitions --how  v'ell  it  responds  to  users,  how  many  projects 
it  *'<n  handle,-  and  how  reliably  it  performs.  The  basic 
c  ir  requirements,  when  overlaid  on  the  functional  and 
:  cneface  requirements,  will  determine  the  type  and  site  of 
:  h;.*  system.  The  selection  of  hardware,  software  and  data 
•v*Y.e  are  ail  influenced  by  these  requirements. 

The  3ize  of  a  SEE  cannot  be  stated  definitively  as  it 
’■pends  on  the  installation.  Sizing  must  consider  factors 
si  oh  ^s :  the  number  of  projects  supported,  the  size  of  the 
P . ejects ,  the  number  and  size  of  simulations,  and  the  user 
porulati  -n.  These  factors  will  influence  the  size  charac¬ 
teristics:  number  and  power  of  processors,  memory,  on- lire 

data  storage,  number  of  I/O  channels,  number  of  user  ter¬ 
minals,  and  off-line  data  storage.  These  sizing  factors 
also  influence  the  support  software:  operating  system, 
utilities,  access  methods,  communications  protocol,  and 
unique  software  requirements. 

The  SEE  must  be  planned  for  no  more  than  60%  of  the 
available  capacity  for  normal  operations.  This  permits 
more  growth  of  the  SEE  during  its  early  years.  The  SEE 
must  be  capable  of  a  200%  growth  in  capacity  through  a 
natural,  design-consistent  expansion  of  the  hardware. 

An  effective  SEE  must  provide  a  stable  environment  for 
the  users.  This  means  not  only  high  reliability  (i.e., 
infrequent  failures)  but  high  availability  (infrequent 
periods  of  extended  outage).  Assuming  that  reliability  is 
high,  availability  can  be  kept  high  by  having  a  well-designed 
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channel ) . 

System  failure:  any  failure  of  a  key  system  component 
that  reruJers  the  entire  support  system  inoperable  and 

for  which  no  backup  is  available. 

Software  can  also  fail: 


Environment  changes:  software  environment  changes  can 
make  a  user  inoperative.  For  example,  if  the  system 
software  has  been  altered  in  some  way  each  user 
has  been  raqnecvnd  to  ma‘<e  a  correspond  i  ng  change  •  ' 
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2.4  Design  Constraints 


Several  SEE  design  constraints  are  mandatory:  it  must 
be  rehostable  (capable  of  being  moved  easily  from  one  host 
to  another  host  computer),  it  must  have  ease  of  extension, 
snd  it  must  support  Ada. 

A  SEE  is  rehostable  if  it  can  be  moved  to  a  different 
nost  computer  and  become  quickly  operable  with  the  instal¬ 
lation  of  the  host-unique  kernel.  The  ability  to  rehost 
a  SEE  can  only  be  achieved  through  extensive  use  of  a 
high-level  language,  and  through  keeping  machine-dependent 
code  within  the  non-transportable  kernel.  All  code  outside 
the  kernel  must  be  independent  of  the  hardware  and  the 
operating  system.  Tools  must  be  completely  portable. 

The  attribute  of  being  extendable  can  be  attained 
ch  •>' gtt  a  flexible  architecture  and  a  standard  interface 
"nr  .iew  tools.  The  flexible  architecture  allows  tailoring 
tv  a  variety  of  hardware  architectures.  New  tools  can  be 
aided  to  the  support  system  if  they  comply  with  minimum 
interface  standards. 


2.4.1  Independence 

The  SEE  design  must  support  independence  of  software 
in  the  following  areas: 

Portable  SEE  ( R)  -  The  support  system  software  must 
be  portable  except  for  the  machine-dependent  kernel. 
The  abstract  interface  to  kernel  services  must  be 
identical  across  all  implementations  of  the  support 
system. 

I/O  Interfaces  (R)  -  All  I/O  devices  must  be  inter¬ 
faced  through  abstract  device  interfaces  to  minimize 
the  impact  of  changes. 

Data  Base  Independence  (R)  -  The  support  system  soft- 
ware,  with  the  exception  of  the  data  base  management 
system,  must  be  unaffected  by  the  physical  organiza¬ 
tion  or  the  location  of  the  data  base. 

Data  Base  Design  (R)  -  The  logical  and  physical 
designs  of  the  data  base  must  be  strictly  separated 
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4.2  Architectural  Flexibility 


The  SEE  must  be  flexible: 

Adaptable  Architecture  (0)  -  The  support  syst»r.'. 
’software"  should  be  adaptable  to  a  distributed 
mini-computer  architecture,  or  to  a  large  mainframe 
architecture,  or  to  a  hybrid  architecture. 

Geographic  Distribution  (0)  -  The  support  system 
software  functions  shoullT~be  adaptable  to  geographic 
distribution.  This  might  be  accomplished  through 
system  generation  changes  alone. 


4.3  Ada  Compatibility 
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sigr.  if  leant  ly  affected  if  software  causes  delays  in  the 
introduction  of  new  systems  or  malfunctions  in  the  weapon 
system.  Either  situation  is  likely,  given  the  stresses  on 
the  software  production  resources  and  the  availability  and 
quality  of  the  software  engineering  practices  and  tools. 


L.l  A  Comparison  of  Two  Systems 


This  section  compares  two  operational  systems  to  show 
the  disparity  in  software  engineering  practices  in  the 
Navy.  The  two  systems  are  not  ECS  but  are  included  under  the 
MIL-STD— 1679  umbrella. 

Figure  A. 1.1-1  contrasts  the  software  engineering 
practices  and  associated  information  for  each  system.  The 
most  striking  attribute  of  the  contrasted  systems  is  that 
each  is  Like  a  snapshot  of  the  software  engineering  practices 
accepted  as  the  norm  during  their  development.  System  A 
reflects  the  middle  1960's,  and  System  B  the  early  1970's. 

The  information,  based  on  a  1980  review,  shows  that  software 
systems  have  an  inertia  which  resists  change.  The  cause 
may  be  a  lack  of  clear  requirements,  or  insufficient 
direction  or  motivation  for  the  maintainers  to  re-engineer 
evolving  software.  Even  with  properly  motivated  maintainers, 
software  engineering  environments  for  existing  systems  are 
not  designed  to  encourage  reengineering. 

Although  these  systems  are  but  a  small  sample  of  Navy 
software  systems,  it  is  useful  to  state  some  generalizations 
based  on  them.  These  generalizations  are  corroborated  by  other 
Navy  groups  and  systems. 

Application  of  Standard  -  Current  standards  are  not 
uniformly  applied  to  Navy  systems,  and  are  not  evident 
at  all  in  older  systems.  Systems  seem  to  persist  in 
their  original  state.  Re-engineering  to  improve  the 
the  software  relative  to  standards  is  uncommon  over 
the  life  cycle  of  software. 

Support  Tools  Hosted  on  Target  Computers  -  In  many 
cases,  the  support  tools  are  hosted  on  the  target 
computer.  This  pervasive  practice  has  been  detri¬ 
mental  to  the  software.  The  target  computers  are 
constrained  in  power  and  resource,  and  they  do  not 
have  a  good  set  of  modern  software  engineering  tools. 
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of  '•.he  late  197Q :  s.  This  disparity  neglects,  to  some 
degree,  the  sophistication  of  the  group  responsible  for 
either  the  original  development  or  current  maintenance. 
Another  factor  is  the  pervasive  practice  of  hosting  devel¬ 
opment  and  maintenance  on  the  target  computer.  The 
restricted  power,  resources,  and  support  facilities  of 
most  existing  target  computers,  in  terms  of  software  engi¬ 
neering,  constrain  what  can  be  done  and  what  is  available. 

Although  the  Navy  has  explicit  standards  for  the  deve 
opment  of  ECS  software,  the  standards  are  unevenly  applied 
Much  of  the  ECS  software  inventory  was  developed  before 
the  adoption  of  MIL-STD-1679 ,  therefore,  the  systems  in 
the  ECS  inventory  shew  varying  degrees  cf  adherence  to 
cu  trend  standards.  For  systems  undergoing  a  aegor  upgrade 
using  cu;;:-dOt  standards  to  develop  the  modified  portion 
of  the  system  Is  often  cost- justified.  This  process  of 
upgrading  the  design  and  '<  mplementat  ion  of  evolving  system 
vill  be  called  ce-ei  g  ine  r  i  rig,  hc-eng  iroo  r  lug  older  Navy 
.I  o r  '..ware  to  on-v-nt  ard.c  is  s  iov<  or  ~\j.  is  tent  :  n 

most  cases. 


The  Navy  has  i.i.iijy  software  support.  sysi., vas  and  ci>. v j 
opment  tools  available.  These  tools  arc  good,  but  they 
address  only  a  small  segment  of  the  software  development 
process,  code  generation  and  test.  Software  production 
•-V.:  lands  are  rapidly  >  ncraasi  ;y  > t  the  5.  ».  mod  ■.  s 1 

■■  unruinc  progrommer  population.  Thus,  chin  v  >l .  car¬ 
rot  improve  productivity  enough  co  bring  j  ;o gee fed  d..,.an..s 
into  balance  with  projected  resources. 


c  :i.. 


The  annual  budget  for  ’h.-vy  software  is  hundreds  ■ 
i  ons  o  '  dollars,  no  the  co.- to  the  .Navy  .or  nud'f- 
n*-  ut  •.  i  epment  a*  r.a  i.n  ’•  e  ■  ■■■>.■  is  ‘  age  •  The  tviihA 

oh  ">uid  p  evoke  c  cnee  r  r.  -it.).:,  iauvjv  j  ng  the  EC?  A-.'- v . . 
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SYSTEM  A  SYSTEM  B 


Date  Operational 

Target  Computer 
Age  of  Target  Computer 
Host  Computer 
Software  Architecture 

Standards 

Modern  Methodologies 

Documentation 

Support  Tools 


1970 

CP901 

@16  yrs. 

CP901 

Outmoded  OS, 

change  difficult, 
no  hierarchic 
structure 

None  evident 


None  evident 


Minimum 

documentation, 

non-standard 

Card-based 

editing 

Tape  libraries 
SYMON/SYCOL 
compiler 

Assembler,  system 
integrator, 
link-11  simulator 


1977 

PDP  11/70 

@7  yrs. 

PDP  11/70 

Modern  OS, 
reasonable 
modularity, 
structured 

Partial 
adherence 
to  1679 

Structured 

programming 

Warnier-Orr 

design 

Formal  T&E 

Good 

documentation , 
non-standard 

On- line 

editing  of 
disk-based 
libraries 

Good  code 
generat ion 
support 
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Reinvention  of  Software  -  In  all  ECS  systems  today, 
many  common  functions  can  be  identified.  Neverthe¬ 
less,  these  functions  are  designed  and  implemented 
anew,  again  and  again,  for  each  system.  Development 
of  reusable  components  could  strongly  affect  produc¬ 
tivity  and  reliability. 

Lack  of  Management  Rigor  -  Rigorous  planning,  con¬ 
figuration  management,  and  quality  assurance  tech¬ 
niques  are  not  consistently  applied  to  most  soft¬ 
ware  development  or  maintenance  projects. 

Lack  of  Sufficient  Correctness  Analysis  -  Correct¬ 
ness  "liriaTysTi-^nT~i^rtware~quaTTtyari—  pursued 
through  testing  alone.  The  necessary  techniques  to 
ensure  high  quality  are  not  used  on  most  projects. 


1.2  Currently  Available  Support  Systems 


Support  Systems;  The  Navy  has  several  support  systems 
for  the  development  and  maintenance  of  ECS  software. 

Machine  Transferable  AN/UYK  Support  Software  -  MTASS 
is  a  software  support"  tool  for  Navy  standard  computer 
systems.  It  consists  of  a  CMS-2  cross-compiler,  a 
MACRO  cross-assembler,  a  loader,  a  system  generator, 
simulators,  and  a  FORTRAN  cross-compiler.  MTASS 
provides  library  support  for  application  programs 
and  can  be  hosted  on  several  different  computers. 

Facility  for  Automated  Software  Production  -  FASP  is 
a  support  system,  developed  by  the  Naval  Air  Develop¬ 
ment  Center  ( NADC ) .  It  is  hosted  on  both  C DC  and 
PDP  mainframes.  FASP  supports  such  languages  as 
SPL/1,  CMS-2,  MACRO,  and  ULTRA;  and  it  produces 
code  for  the  AN/AYK-1 4 ,  AN/UYK7 ,  AN/UYK-20,  AN/UYX-32, 
and  AN/UYS-1  computers.  It  features  an  integrated 
data  base  containing  programs  as  well  as  project 
management  information.  Tools  available  include  a 
text  editor,  compilers,  assemblers,  linkers,  loaders, 
target  computer  simulators,  unit  test  tools,  and 
management  reporting  aids. 

5HARE/7  -  SHARE/7  is  a  multiprocessor  timesharing 
system  hosted  on  the  AN/UYK-7  computer.  It  provides 
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an  interactive  environment  for  the  software  develop¬ 
ment.  It  includes  a  text  editor,  on-line  debugging 
aids,  compilers,  assemblers,  loaders,  target  computer 
simulators,  and  a  text  formatter.  The  language  proc¬ 
essors  generate  code  for  the  AN/USQ-20,  AN/UYK-7, 
and  AN/UYK-4 3  computers.  SHARE/7  supports  CMS-2, 
FORTRAN,  SPL,  BASIC  and  several  assembly  languages. 

These  three  Navy  software  support  systems  are  well- 
conceived,  useful  systems,  however,  they  are  limited 
since  they  address  only  code  generation  and  unit  test. 

The  important  functions  of  requirements  analysis,  specifi¬ 
cation,  and  design  are  inadequately  supported.  Correctness 
analysis  also  lacks  support.  There  is  a  real  need  to 
extend  support  beyond  the  scope  of  these  systems. 

Simulation/Stimulation  Systems;  Another  type  of  support 
system  required  for  ECS  software  development  and  maintenance 
is  an  environment  simulation  system.  These  systems  are 
sometimes  called  s imulation/stiraulation  systems  or  simply 
sim/stim.  The  Navy  has  developed  and  operates  many  of 
these  systems  today  for  training  and  testing.  A  sim/stim 
system  might  consist  of  (1)  one  or  more  computers  to  host 
the  environment  simulation  software,  (2)  special  devices 
to  interface  the  environment  simulation  computer  to  the 
ECS  or  other  tactical  hardware,  and  (3)  a  configuration 
of  the  ECS  along  with  some  subset  of  tactical  hardware. 

Although  the  Navy's  sim/stim  systems  have  many  common 
functions,  each  sim/stim  system  has  been  developed  with  no 
attempt  to  create  a  set  of  reusable  components.  Since  15  to 
20  (or  more)  such  systems  exist,  each  costing  from  $10  to 
$30  million  to  develop  (plus  more  for  maintenance),  the 
Navy's  cost  for  this  redundancy  is  significant. 


1.3  A  Case  Study 


A  functional  analysis  of  one  Navy  software  production 
group  was  performed  as  part  of  a  software  automation  pro¬ 
gram.  This  functional  analysis  shows  some  of  the  problems 
and  dynamics  faced  by  Navy  software  production  groups 
today.  The  following  observations  are  derived  from  the 
final  report  which  was  prepared  by  Systems  Consultants, 
Inc.,  October  15,  1980. 
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Figure  A. 1.3-1  vividly  illustrates  a  common  state  in 
software  production  groups  today-1-.  Most  of  the  automated 
resource  is  dedicated  to  code  generation  and  test,  with 
little  or  none  of  the  resource  supporting  the  activities 
of  specification  and  design. 


The  functional  analysis  lata  shows  a  very  disturbing 
trend  of  rapidly  increasing  workload  in  the  face  of  constant 
or  decreasing  resources.  Figure  A. 1.3-2  shews  the  projected 
work  load  between  1980  and  1990  against  the  available  work 
force  (based  on  current  budgets}.  The  imbalance  is  over¬ 
whelming.  Even  if  the  budgets  could  be  increased,  the 
facility  probably  could  not  hire  the  qualified  programmers 
because  of  the  projected  programmer  shortage. 


A  similar  problem  exists  for  the  support  systems  and 
mcckups  used  for  testing.  Figure  A. 1.3-3  shows  the  addi¬ 
tional  systems  which  would  be  needed  to  support  the  pro¬ 
jected  work  load.  These  additional  systems  represent  a 
significant  capital  investment.  They  will  also  require 
floor  space  not  available  at  the  facility. 


The  functional  analysis  attests  strongly  to  the  prob¬ 
lems  facing  the  Navy  in  ECS  software.  Accelerating  growth 
in  the  workload  will  soon  overwhelm  the  production  resources 
and  thereby  threaten  fleet  readiness.  Increasing  the  pro¬ 
duction  resources  to  handle  the  work  load  is  not  feasible 
because  of  the  cost  and  projected  shortage  of  qualified 
programmers.  The  only  answer  is  to  increase  the  produc  tivity 
of  the  available  work  force.  This  cannot  be  done  w  thout 
a  significant  improvement  in  the  support  systems,  methodol¬ 
ogies  and  tools  used  by  these  groups.  The  current  support 
systems  are  too  narrow  in  scope  to  meet  future  needs. 


2.  Modernization  and  R&D  Activities 


Many  people  in  the  Navy  have  recognized  the  need  to 
improve  the  way  software  is  developed  and  maintained. 
Several  Navy  activities,  aimed  at  developing  improved 
methodologies,  tools  and  support  systems,  have  air  ady 
begun.  In  the  past,  these  activities  were  not  coo  dinated, 


1  The  figures  in  this  section  are  copies  of  charts  pre¬ 
pared  by  W.  Rosen  of  NOSC. 


Figure  A.1 .3  1 :  Application  of  Automated  Support 
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and  they  often  duplicated  one  another.  Recently,  the  Navy 
has  taken  two  significant  steps  to  provide  better  focus 
for  mode rni. rat  ion  of  software  engineering. 

Coord inat ion  o f  Planning  for  Exploratory  Developme nt  - 
This  activity  is  part  of  Program  6  within  the  Navy's 
RDT&E  accounts  (Research,  Development,  Test  and 
Evaluation)  and  is  referred  to  as  "6.2"  resource. 

Within  the  NAVAIR,  NAVELEX  and  NAVSEA  system  commands, 
people  involved  in  6.2  planning  and  control  have 
begun  a  cooperative  effort.  This  effort  will  produce 
a  coordinated  6.2  plan  for  software  engineering. 

It  should  provide  a  better  focus  for  5.2  resource 
and  a  more  effective  investment  of  the  resource. 

Software  Engineering  Environment  Working  Group  (SEEWG)  - 
MAT-08Y  established  the  SEEWG  to  recommend  "ways  to 
eliminate  redundant  development  activities  for  support 
systems,  and  to  focus  efforts  on  developing  a  modern 
Navy  SEE.  The  SEEWG  includes  members  from  all  Navy 
system  production  groups  and  system  centers  involved 
in  the  development  and  maintenance  of  ECS  software. 


The  results  of  these  efforts  will  not  be  evident  for  some 
time  because  the  number  of  modernization  activities  is  large. 
The  following  subsections  provide  a  sampling  of  these  activ¬ 
ities. 


2.1  Modernization  of  Support  Systems 


In  a  preliminary  survey  of  its  members,  the  SEEWG  iden¬ 
tified  more  than  20  Navy  modernization  efforts  in  software 
development  or  sim/stim  systems.  The  list  is  far  from 
complete  and  does  not  include  similar  efforts  by  Navy 
contractors  to  upgrade  their  in-house  capabilities.  These 
modernization  activities  include  developing  project-specific 
support  systems,  as  well  as  extending  MTASS ,  FASP,  and 
SHARE/7  described  in  Section  1.2.  Summarized  below  are 
two  important  examples  of  modernization  efforts. 

TRIDENT  Software  Support  System  -  TSSS  is  a  support 
system  recently  installed  1  or  development  and  main¬ 
tenance  of  TRIDENT  ECS  software.  Hosted  on  two  I3M 
4341  computers,  it  uses  many  standard  IBM  software 
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t-.urkages  for  library  control,  text  ed icing,  document 
production,  etc.  An  attached  AN/UYK-7  compiles 
CMS -2  code  and  runs  unit  tests.  TSSS  supports  code 
generation,  unit  test,  and  documentation. 

MAVriFX  Software  Support  Facility  ■  5£"  ;  -  r*:v.~  ,  «.  ■' 

hat  submitted  a  Program  Objectives  Memo c and .im  _o 

acquire  a  software  support  facility  for  use  by 
NAVSLEX  software  production  groups.  About  $60 
million  is  required  for  construction,  computer 
hardware,  software  development,  and  personnel  to 
staff  the  SSF. 

The  two  modernization  activities  described  above  have 
several  significant  differences.  The  main  difference  is 
that  TSSS  is  aimed  at  the  support  of  a  single  program 
whereas  SSF  will  support  a  number  of  NAVELEX-sponsored 
programs.  These  two  support  systems  would  not  be  likely 
to  foster  similar  methodologies  or  uniform  applications  of 
standards.  Also,  tools  from  one  are  not  likely  to  be 
transferable  to  the  other. 

Two  modernization  activities  (out  of  many  in  the  Navy) 
for  sim/stim  support  systems  are  described  below. 

Integrated  Simulation  System  -  ISS  is  a  distributed 
sim/stim  system  under  development.  It  can  drive 
simultaneous  testing  in  multiple  mock-ups.  It  will 
run  on  two  to  ten  PDP  VAX  11/780' s  connected  in  a 
bus  architecture,  and  it  will  support  the  sim/stim 
needs  of  its  facility. 

Land-Based  Integration  Test  and  Training  System  - 
LITTS  is  a  program  in  the  planning  stage.  The  main 
objective  is  to  replace  an  older  evaluation  facility. 
Another  objective  is  to  design  LITTS  to  replace  the 
many  sim/stim  systems  used  by  TRIDENT  for  sonar, 
development  of  defensive  weapon  systems,  ma: ntonanee 
train:  no,  etc.  The  push  for  LITTS  comes  . oir,  -_re 
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no.  ,ro  been  ;i:jed  success  f  i  *  ly  or~  several  p  oduet  ’n 
p  r  o  ’  e  c  t 3  . 

;.'er:ocjidnce  Oriented  Design  -  TOO  is  a  modeling 
fool  under  development  for  the  Navy  by  3GS ,  Inc. 
It  provides  a  means  to  assess  he  expected  perfor 
ira.-.ce  of  a  system,  elver.  the  design  in  some  state 
of  development. 
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Tr.e  projects  described  above  ar.d  many  otners  sponsored 
throe  ah  Navy  Pod  .-.re  /e  ry  promising ;  '.owevei,  they  wi.l 
have  no  impact  if  they  are  not  broadly  transfer  tea  into 
production  software  operations.  Technology  transfer  is 
crociai  to  the  accelerated  improvement  ...  twj  ware 

engineering  practice. 
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GLOSSARY 


The  purpose  of  the  Glossary  is  to  explain  the  terns, 
pnrases  and  acronyms  as  they  are  used  within  this  document. 
The  definitions  are  provided  to  promote  understanding;  they 
are  not  offered  as  a  standard  for  terminology  within  the 
Navy  or  industry. 
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„-''i  ie  •  Computer  Systems  project  which  has  ,;:e  object :  v>; 
of  designing  and  implementing  a  SEE  to  improve  FCDS3A 
software  production. 


S  £ 


c 


-  i  r.  i  n 
case.  A 
the  scff 
sot  twa  re 
process 
des igned 


tegrated,  computer-based  support  system  and  data 
SEE  is  designed  to  improve  the  effectiveness  of 
ware  development  process  by  creating  mere  reliao 
;  it  uses  a  well-designed  software  engineering 
with  proven  methodologies  and  flexible,  well- 
tools. 


semantic  analysis  -  evaluation  of  semantic  information  to 
determine  the  completeness  and  consistency  of  the  infor¬ 
mation. 

semantic  language  processor  -  software  iesirned  to  check 

syntax  of  a  specific  formal  language  and  to  record  it  for 


Glossary  Paae  G-21 

***w*-*w)-**Tlr****l»****-************************#*-**,,*i»lr,rJ*#,r**,i 


release  -  a  self-contained  copy  of  a  system  or  system  com¬ 
ponent;  which  can  be  installed  in  the  field  ; normally  a 
-..'.reject  has  several  releases  over  its  _  :  fe  nacr 

relation  that  identifies  alx  data  objects  oe_or.gi.ng  rc 
(controlled  by)  a  release. 

reliaoilitv  -  the  ability  of  a  functional  unit  to  operate 
without  failure  for  a  stated  period  of  time  under  stated 
conditions. 

reliaoilitv  model  -  a  support  tool  for  correctness  analysis; 
this  tool  uses  the  error  history  of  the  system  over  its 
life  cycle  to  estimate  reliability  based  on  attributes 
such  as  size  and  complexity. 

report  generator  -  a  generalized  tool  for  creating  reports; 
parameters  are  used  to  define  the  content  of  the  report 
and  the  data  source,  and  then  the  report  generator  soft¬ 
ware  automatically  creates  the  report. 

requirement  -  a  binding  condition  which  states  a  mandatory 
characteristic  of  an  abstract  or  physical  object;  require 
merits  may  have  different  form:  a  specific  description, 
a  constraint,  an  evaluation  criteria  for  judging  quality, 
or  implied  by  context. 

requirements  analysis  -  analysis  of  the  feasibility  of 

requirements  while  at  the  specification  and  design  level, 
and  prior  to  development  of  the  system. 

resource  -  a  means  to  accomplish  a  task;  a  resource,  in  the 
management  sense,  refers  to  the  money,  time,  people  or 
facilities  available  to  accomplish  a  task. 

resource  estimation  model  -  a  management  tool  which  uses  the 
measurements  from  past  projects,  along  with  a  character¬ 
ization  of  the  system  to  be  developed,  to  generate 
resource  estimates  for  planning. 

reusable  component  -  a  software  component  performing  a  spe¬ 
cific  function  and  deliberately  designed  for  reuse,  with 
options  or  variations  in  function  to  be  selected  via 
parameters;  reusable  components  would  be  of  known  high 
reality,  witn  function  and  parameters  weil-documentec, 
and  freely  available  on  system  libraries. 

review  -  a  methodology  used  to  gauge  the  internal  complete- 
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•  m  1 1  'ey  assurance  or  QA  -  “he  process  of  ensur  1  ng  that  a  or  ;c 
:yste::’  nr  software  .aoi.-fs  gee-def  i  :>-d  s*  uudar  Is . 

•:  :<i  ty  -  a  specific  request  by  an  interactive  user  for  data, 
instruct. ions  r  status;  the  request,  will  elicit  a  response 
from  the  system. 

queueing  tneory  -  one  xa 
'.  -  ms  char  act  e  r  1  z<’d  by- 
servers  ; processors , . 


enema ciuai  1  •:•  „  ;  .  ~ 4-  /  • -.  ~g 

queues  <  items  to  he  •  r  tc"-.sed  ‘ 


record  -  a  collection  of  related  data  items  treated  as  a  unit 

recovery  -  the  activities  associated  with  regain  inq  i  prior 
correct  state  after  an  error  has  occurred. 

.v  J  •  sect  ion  -  the  ability  to  define  (as  a  non-standard 

■-tquence;  what  program  wi  11  receive  tr.e  output  or  a  pro¬ 
gram  which  has  ended  either  normally  or  abnormally;  pipe¬ 
lining  deals  with  standard  sequences,  redirection  with 
non- s  t a nda r d  s eq ue nee s . 

re-engineer  -  the  process  of  upgrading  the  design  and  imple¬ 
mentation  of  existing  systems. 

reflow  -  moving  words  from  one  line  of  text  to  another  to  put 
as  many  words  as  possible  between  a  line's  boundaries; 
reflow  is  used  after  continuous  typing  to  create  blocks 
of  text,  or  after  changing  line  boundaries,  or  tc  justify 
ragged-right  text. 

rehcstable  -  capable  of  being  moved  to  a  different  host  com¬ 
puter  and  becoming  operative  quickly  with  the  installation 
of  the  host-specific  kernel. 


relational  data  base  -  a  data  base  in  which  data  iDjects  a: 
organized  as  a  collection  of  rectangular  cables,  each 
table  being  a  relation;  users  produce  new  relations  by 
combining  old  ones  (by  the  use  of  a  non-procedural  data 
manipulation)  and  do  not  need  to  knew  the  structure  or 
format  of  the  data  base,  especially  the  physica.  struc¬ 
ture. 


regression  testing  -  a  testing  technique  whic 
the  function  which  has  cnanned. 


:n_v  res' 
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executed  separately  to  produce  a  specific  result. 

processor  -  the  component  of  a  computer  which  is  capable  of 
sequentially  and  non— sequent ial lv  interpreting  and  per¬ 
forming  executable  machine  instructions. 

product  -  the  end  result  of  an  activity  within  the  software 
engineering  process;  for  example,  a  specification  is  the 
product  of  requirements  analysis 

productivity  -  a  measure  of  output  per  unit  of  resource  applied. 

program  -  a  sequence  of  instructions  designed  to  make  a  computer 
perform  a  specific  function. 

program  overlay  -  part  of  a  program  which,  when  loaded  into 
a  computer's  memory,  will  overlay  or  replace  all  or  part 
of  a  previously  loaded  segment  or  data  of  a  program. 

programmer's  work  space  -  the  resources  (notably  data  space) 
controlled  by  an  individual  for  performing  their  work 
assignment. 

program  skeleton  -  a  partly-created  program  which,  with 
simple  extensions,  can  be  used  to  create  a  new  program. 

project  -  an  organizational  entity  with  an  assigned  develop¬ 
ment  responsibility;  a  macro  relation  that  identifies  all 
data  objects  belonging  to  (controlled  by)  a  project. 

proof  technique  -  rigorous  techniques  for  proving  a  program 
correct  or  incorrect;  proof  techniques  can  be  either  for¬ 
mal  or  informal;  formal  proofs  use  systematic  logical  ana¬ 
lysis  and  proof  tables  to  derive  correctness  of  prime 
programs,  while  informal  techniques  use  a  series  of 
rigorous  correctness  questions. 

prototype  -  the  creation  and  study  of  an  abstract  model  which 
will  allow  evaluation  of  requirements  and  design 
approaches. 

PSL/PSA  -  Problem  Statement  Language/Prcblem  Statement  Analyzer. 


23S  -  Query-by-Examp le  ; tm.  >  - 
language . 


I3M's  relational  data  base  query 
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PERT  -  Program  Evaluation  and  Review  Technique;  a  specific 
tool  for  determining  critical  path  and  resource  measures 
in  a  complex  project  environment. 

physical  structure  -  how  data  is  physically  organized  and 
structured  on  a  data  storage  device. 

pipelining  -  the  ability  to  define  the  normal  output  of  one 
program  as  the  normal  input  to  another  program,  both  pro¬ 
grams  being  considered  a  standard  sequence;  redirection 
deals  with  non-standard  sequences. 

FOD  -  acronym  for  Performance  Oriented  Design,  a  modeling 
tool  under  development  for  the  Navy. 

portability  -  a  software  component  is  portable  when  it  can 
be  moved  to  another  host  without  any  change  to  the  com¬ 
ponent;  it  is  rehostable  if  a  different  host-specific 
kernel  is  required. 

portable  -  software  which  requires  only  the  host-specific 
kernel  to  run  on  a  different  host  computer. 

power  -  the  ability  of  a  programming  language  to  handle 
sophisticated  problems  simply  and  directly. 

PPS  -  Program  Performance  Specification  -  describes  the 

performance  specification  for  a  given  software  item  cn  a 
given  computer  system. 

preprocessor  -  software  which  does  a  preliminary  computation 
or  organization  of  source  statements  before  it  is  compiled 
or  assembled;  some  source  statements  contain  preprocessor 
statements  which,  when  executed  by  the  preprocessor, 
alters  the  source  statements. 

pretty  printer  -  software  which  formats  listings  to  make  them 
easier  to  read  and  understand. 

private  data  -  data  in  an  individual’s  work  space  which  is 
controlled  by  the  individual. 

procedure  -  a  set  of  unique  instructions  for  performing  a 
specific  function. 

process  -  any  unique  sequence  of  instructions  which  can  be 
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the  output  of  a  compiler  or  assembler;  object  Modules 
•.an  be  ext-c  -Led  directly  on  the  cory  rter  '  wt  are  norma  1  !•••• 
connected  with  other  object  modules  cy  a  linkage  ed.jor 
to  produce  load  modules. 

off-line  -  pertaining  to  peripheral  devices  (such  as  magnet, 
tapes  or  disks)  which  are  not  directly  connected  to,  or 
accessible  by,  the  processing  unit  of  i  computer  system. 

on-line  -  pertaining  to  peripheral  devices  which  are  direct! 
connected  to,  or  accessible  to,  the  processing  unit  of  a 
computer  system. 

operating  system  -  system  software  that  enables  a  data  pro¬ 
cessing  system  to  supervise  its  own  operations,  and  opti¬ 
mize  the  use  of  all  hardware  and  software  resources  by 
automatically  invoking  system  programs,  application  pro¬ 
grams,  language  processors,  and  data  to  ensure  continuous 
processing  of  a  series  of  jobs. 

operators  and  operands  -  technique  for  measuring  the  com¬ 
plexity  of  a  low  level  design  (Halstead  [77]). 

over-constraining  requirements  -  requirements  which  constric 
the  latitude  needed  by  designers  to  consider  alternative 
approaches,  thus,  possibly,  excluding  an  excellent  design 
approach. 


patch  -  executable  code  (either  absolute  machine  code,  or 
translated  machine  code  from  source  statements)  used  for 
making  an  immediate  fix  to  a  software  fault. 

path  test  analyzer  -  a  tool  used  to  examine  possible  paths 
through  a  segment  of  code  and  to  generate  test  cases  for 
these  paths. 

PDL  -  Program  Design  Language;  a  methodology  for  formally 
recording  a  program  design;  PDL  is  sufficiently  clear  to 
support  direct  coding  but  flexible  enough  to  leave  some 
questions  unanswered  while  proceeding  with  design. 

PDR  -  Preliminary  Design  Review  -  a  formal  review  of  the 
early  high-level  design  of  a  system. 

performance  -  the  capacity  of  a  system  to  achieve  a  desired 
result;  a  productivity  measure  for  a  system. 
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me Jel  -  a  technique  by  which  an  abstraction  of  system  is 

created  eo  that  it  can  be  analyzed,  and  different  sets  of 
variables  evaluated;  models  are  usually  mathematical  in 
nature  but  can  be  semantic. 

module  -  module  is  used  very  specifically  in  this  document 
to  mean:  a  component  of  the  system-level  design  which  is 
defined  through  the  technique  of  information-hiding,  and 
decomposes  into  other  modules  or  into  programs  and  data 
structures. 

MTASS  -  Machine  Transferable  AN/UYX  Support  Software;  a  set 
of  software  used  for  support  and  kept  current  by  the  Navy. 

mutation  -  a  micro  relation  that  refers  to  version  variations 
of  a  system. 


NADC  -  Naval  Air  Development  Center. 

NCCS  -  Naval  Command  and  Control  System. 

NAVAIR  -  Naval  Air  Systems  Command. 

NAVELEX  -  Naval  Electronics  System  Command. 

NAVSEA  -  Naval  Sea  Systems  Command. 

nesting  -  the  process  of  embedding  structures,  data,  or  sub¬ 
routines,  within  others  at  a  different  hierarchic  level. 

non-baseline  data  -  temporary  information  which  is  useful  to 
the  task  at  hand  but  is  not  worth  keeping  permanently;  as 
an  example,  debug  information  from  a  test  run  is  essential 
to  the  testing  process  but  is  not  needed  once  the  test  suc¬ 
ceeds  . 

non-orocedurai  techniques  -  techniques  for  problem  solving 
which  do  not  require  an  established  sequence  of  steps  or 
instructions . 

NOSC  -  Naval  Ocean  Systems  Center. 

NUSC  -  Naval  Underwater  Systems  Center. 


object  module  -  executable  machine  instructions  which  are 
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media,  that  can  oe  sensed  by  machines  designed  for  that 
purpose . 

macro  relations  -  those  -eiations  between  items  in  a  data 
base  which  encompass  a  large  number  of  data  base  objects; 
the  nine  macro  relations  are:  baseline  products,  non- 
Daseline  products,  measurements ,  archive,  system  support 
library,  project,  release,  version,  and  increment;  also 
see  micro  relations. 

mailbox  -  a  message  technique  used  to  communicate  between 
individuals  or  groups. 

maintenance  -  see  adaptation. 

management  -  the  function  concerned  with  all  activity 

involved  in  the  development  and  adaptation  of  software. 

mapping  -  a  correlation  between  two  sets  of  data;  e.g.,  the 
format  of  a  system  specification  would  be  based  on  the 
semantic  categories  and  relations  chosen  to  define  the 
system  requirements. 

MAPSE  -"Minimum  Ada  Programming  Support  Environment. 

measurement  data  -  data  objects  of  a  quantative  nature  rep¬ 
resenting  some  characteristic  of  the  software  development 
process;  measurement  data  is  used  by  management  to  assist 
in  the  planning  and  control  of  a  project. 

methodology  -  a  repeatable  human  procedure  or  set  of  proce¬ 
dures  that  is  used  to  translate  data,  which  is  input  to  a 
life  cycle  activity,  into  data  which  is  the  output  of  the 
activity;  a  well-conceived  methodology  provides  for  the 
separation  of  the  creative,  intellectual  aspects  of  an 
activity  from  the  more  clerical,  mechanical  aspects. 

micro  relations  -  those  relations  between  items  in  a  data 
base  which  have  significance  in  the  context  of  a  small 
number  of  data  base  objects;  the  micro  relations  discussed 
are:  traceability,  derivation,  ancestry,  version  .'muta¬ 

tion  of  a  system  or  release),  and  association;  also  see 
mu^ro  relations. 

'•ilestone  -  a  checkpoint  marking  the  completion  of  a  signi¬ 
ficant,  clearly  identifiable  activity  or  task. 
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interpreter  -  software  which  executes  the  instructions  of  an 
interpretive  language  one  at  a  time;  APL  is  an  interpre¬ 
tive  language. 

ISS  -  Integrated  Simulation  System 


job  -  a  unit  of  work  for  a  computer;  a  ]ob  normally  includes 
all  of  the  system  commands,  programs,  linkages,  and  files 
needed  to  perform  a  complete  unit  of  work. 

job  control  language  -  a  problem-oriented  language  used  to 
identify  and  specify  all  operations  to  be  performed  for 
a  job. 


LAMPS  -  acronym  for  Light  Airborne  Multipurpose  System. 

language  analyzer  -  a  tool  for  analyzing  a  specification 
written  in  a  formal  language. 

Life  cycle  -  the  set  of  activities,  and  the  relations  among 
these  activities,  involved  in  the  development,  operation, 
and  continuing  adaptation  of  a  software  system,  beginning 
with  its  conception  and  continuing  to  its  removal  from 
use . 

linker  or  linkage  editor  -  system  software  which  creates 

strings  or  sequences  of  executable  code  by  resolving  cross 
references  and  connecting  separate  units  of  object  code. 

LITTS  -  Land-Based  Integration  Test  and  Training  System. 

load  module  -  programs  in  the  form  appropriate  for  execution 
by  a  computer;  load  modules  are  the  output  of  a  linkage 
editor  after  it  processes  the  appropriate  object  modules. 

loader  -  system  software  which  reads  data  and  executable  code 
into  a  computer's  memory. 

Log  -  a  sequential  file  which  contains  time-ordered  transac¬ 
tions  against  a  data  set. 


machine  code  or  machine  language  -  see  ooject  code. 


mach  me  -  re  ad  a  o  le 


properly  structured  data,  on  a  suitaole 
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Implementation  -  the  software  development  activity  concerned 
with  the  creation,  unit  test,  and  integration  of  code 
fulfilling  a  design. 

increment  -  a  management  unit  of  a  project  associated  with 
incremental  development  (one  or  several  increments  may 
equal  a  release);  a  macro  relation  that  identifies  all 
data  objects  belonging  to  (controlled  by)  an  increment. 

incremental  development  -  the  concept  of  defining  and  build¬ 
ing  software  in  small  pieces,  with  each  succeeding  one 
resulting  in  a  viable  operational  system  with  more 
function. 

independent  -  a  quality  of  software  by  which  it  is  free  from 
the  influence  of  specific  features  offered  on  a  computer 
system  (hardware)  or  an  operating  system  (software). 

index  -  a  list  of  the  contents  of  a  data  base  and  contain¬ 
ing  references  to  locate  a  specific  item. 

information-hiding  -  a  technique  involving  the  isolation  of 
information  within  modules;  module  boundaries  are  defined 
by  the  particular  information  to  be  isolated,  such  as 
design  decisions  and  data  definitions.  Information-hiding 
decisions  are  made  on  the  basis  of  expected  changes  to 
information  thus  localizing  the  effect  of  future  changes 
to  one  module. 

inspection  -  a  technique  for  evaluating  the  correctness  of 
a  design,  specification,  code  segment,  test  plan,  etc.; 
inspections  involve  a  small  group  of  specific  people  fol¬ 
lowing  a  well-defined  procedure  (Fagan  [75]). 

instrumented  analysis  -  a  methodology  which  captures  data 
dynamically  (during  execution)  and  uses  it  to  identify 
and  locate  errors. 

integration  -  the  software  development  activity  which  com¬ 
bines  parts  of  a  system  to  create  a  viable,  operable  system. 
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graceful  failure  -  a  failure  which  only  incapacitates  a  part 
of  a  system  rather  than  the  entire  system. 

graphics  -  a  pictorial  means  of  presenting  information; 

usually  on  paper  but  can  also  be  on  an  interactive  device 
which  displays  graphics . 


hardware  simulator  -  software  which  duplicates  the  opera¬ 
tional  characteristics  of  a  hardware  device. 

H CM  -  Hierarchical  Development  Methodology;  a  methodology 
for  specifying ,  designing,  and  implementing  software;  it 
i.so  supports  formal  verification, 

I  o  mechanism  -  an  interactive  feature  which  allows  the  user 
fa  be  prompted  or,  how  to  perform  an  operation,  or  how  to 
solve  a  problem. 

!.e  r i  Stic  -  literally,  helping  to  discover  or  learn;  a 

Heuristic  process  modifies  itself  based  on  past  perfor¬ 
mance,  while  making  progress  toward  an  acceptable  result; 
progress  is  based  on  a  series  of  approximations  toward 
that  result.  Heuristics  is  currently  syncnomous  with 
artificial  intelligence  (AI)  and  is  used  in  knowledge- 
based  expert  systems. 

hierarchic  data  base  -  a  data  base  in  which  data  objects  are 
organized  in  a  specific  hierarchy  relative  to  one  another; 
users  must  know  and  understand  the  hierarchy  to  manipulate 
data  with  ease. 

high-level  language  -  a  programming  language  whose  instruc¬ 
tions  do  not  bear  a  one-to-one  relationship  with  the 
generated  machine  instructions;  a  high-level  language  may 
either  oe  a  problem-oriented  language  like  FCPTRAN  or  a 
universal  language  such  as  COBOL. 

host  or  host  computer  -  a  general-purpose  computer  system 
with  extensive  support  software  and  capacity;  software 
should  oe  developed  on  a  large  scale,  we  11- supported 
host  rather  than  a  target  computer  unless  the  target 
computer  is  large  scale  and  well-supported ;  once  the 
software  is  developed  it  would  be  loaded  into  the  target 
computer  for  operational  use. 
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FASP  -  acronym  for  retell  ity  for  Automated  Software  Produc¬ 
tion,  a  large  support  system,  which  uses  commercial  com¬ 
puters  and  was  developed  by  Naval  Air  Development  lenter 
( NADC ) . 

failure  -  the  degradation  of  a  system  when  an  error  occurs; 
see  error. 

fault  -  an  incorrect  implementation  of  the  specification; 
see  error. 

FCDSSA  -  Fleet  Combat  Direction  Software  Support  Activity  1 
San  Diego  (FCDSSASD)  and  Dam  Neck  ( FCDSSADN ) . 

feasibility  analysis  -  an  evaluation  to  determine  whether 
there  exists  a  design  which  satisfies  the  requirements 
within  system  constraints. 

file  -  a  collection  of  related  records  treated  as  a  unit. 

firmware  -  software  residing  in  read-only  memory. 

foreground  -  an  operating  system  usually  has  two  modes  of 
operation:  background  and  foreground;  foreground  is 
biased  toward  servicing  short,  interactive  work  requests 
on  a  high  priority  basis,  and  background  is  biased 
toward  larger  work  requests  (jobs)  which  are  queued  and 
serviced  on  a  scheduled  or  FIFO  (first-in-first-out) 
basis  as  system  resources  come  available. 

formalism  -  the  mathematical  or  logical  structure  of  an 
argument  as  distinguished  from  its  content. 

formatting  tool  -  a  tool  for  transforming  software,  or  a 
document,  into  a  specific  format. 

FORTRAN  -  acronym  for  FORmula  TRANslation,  one  of  the  first 
high-level  languages  which  was  commercially  available; 
FORTRAN  was  designed  for  writing  programs  to  solve  prob¬ 
lems  which  could  hr-  stated  mathematically. 
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entry  point  -  the  point  within  a  program  to  which  control  is 
passed  by  another  program;  each  executable  program  should 
have  one  entry  point  and  one  exit  point. 

environment  simulator  -  a  testing  tool  which  simulates  an 
operational  environment. 

error  -  a  discrepancy  between  the  correct  value  or  condition, 
and  the  actual  value  or  condition.  An  error  is  a  mani¬ 
festation  of  a  fault  during  execution  and  may  cause  a 
failure;  a  fault  is  an  incorrect  implementation  of  the 
specification;  and  a  failure  is  the  degradation  of  a  sys¬ 
tem  when  an  error  occurs. 

error-day  -  the  average  time  (in  days)  a  potential  error- 
causing  fault  goes  undetected. 

error  handling  -  see  exception  handling. 

estimation  model  -  software  which  uses  a  data  base  of  meas¬ 
urements  on  performance  of  past  projects,  along  with  a 
description  of  the  new  project,  to  generate  estimates  for 
the  development  activities  of  a  new  system. 

exception  handling  -  the  special  processing  triggered  by  an 
abnormal  (usually  erroneous)  condition. 

executable  design  -  a  design  in  a  formal  language  which  can 
be  interpretively  evaluated  to  determine  the  design's 
completeness,  performance  and  correctness. 

extendability  -  the  ability  to  add,  easily  and  with  minimum 
rework,  new  functions  to  an  existing  system. 

external  interface  -  a  shared  boundary  between  a  component 
of  a  system  and  a  component  considered  to  be  outside  the 
system. 

external  reference  -  a  program  reference  to  a  symbol  out¬ 
side  of  the  program;  external  symbols  and  external 
references  are  resolved  either  statically  by  a  linkage 
editor  or  dynamically  by  a  loader. 

external  symbol  -  a  symbol  defined  in  an  owning  program  as 
available  to  other  programs  outside  the  owning  program. 
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the  specification,  provides  a  description  for  implementa¬ 
tion,  and  is  feasible  within  the  appropriate  constraints 
(time,  schedule,  cost,  etc.) 

development  -  all  the  activities  needed  to  specify,  design, 
implement,  test,  document,  and  manage  the  creation  or 
alteration  of  software. 

diagnostics  -  warnings  or  error  messages  pertaining  to  the 
isolation  and  detection  of  a  potential  problem,  malfunc¬ 
tion  or  error. 

directed  graph  -  consists  of  a  set  of  nodes  and  directed 
links  connecting  nodes,  and  has  an  implied  direction;  a 
PERT  chart  is  a  directed  graph;  an  acyclic  directed 
graph  is  a  directed  graph  in  which  no  sequence  of  links 
leaving  a  node  ever  returns  to  it. 

distributed  data  base  -  a  data  base  whose  components  can  be 
geographically  separated  yet,  conceptually  and  operation¬ 
ally,  are  considered  part  of  the  same  data  base. 

down-line  load  ■  the  process  of  moving  data  or  programs  from 
a  host  computer  to  a  target  computer  over  a  channel-to- 
channel  link. 

driver  -  code  that  simulates  the  activity  of  a  superior 

software  component  while  testing  a  subordinate  component. 

dump  -  the  mass  transfer  of  data  from  one  medium  (normally 
internal)  to  another  medium  (normally  external)  either  as 
a  safeguard  against  errors  or  as  an  aid  to  debugging. 

dynamic  analysis  -  analysis  techniques  which  examine  an  item 
by  running  it  in  a  known  environment;  the  correctness 
analysis  activity  uses  dynamic  analysis  through  a  variety 
of  testing  techniques  with  known  inputs  and  known  environ¬ 
ment. 


ECP  -  engineering  change  proposal;  a  requested  change  to 
hardware  or  software. 

ECS  -  Embedded  Computer  System;  a  Navy  system  containing  an 
embedded  computer  and  requiring  software  support. 

EIA  -  Electronic  Industries  Association. 
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variable,  and  a  different  program  accesses  the  variade 
and  uses  it. 

data  dictionary  -  a  central  collection  of  definitions 

describing  the  names  and  attributes  of  data  elements  in 
a  data  base. 

data  flow  analysis  -  a  design  methodology  which  uses  the 
movement  of  data  in  a  system  to  decompose  functions  or 
modules . 

data  object  -  abstraction  for  the  attributes  and  values  of 
data. 

data  reduction  -  the  processing  performed  on  data  to  trans¬ 
form  it  from  one  form  to  another. 

data  structure  -  a  technique  for  organizing  data  into  a  more 
convenient  form  for  manipulation  without  regard  for  its 
actual  physical  structure,  e.g.,  a  record  of  30  data  ele¬ 
ments  is  more  convenient  to  process  than  30  separate  data 
e lements . 

DBMS  -  see  data  base  management  system. 

debug  -  an  informal  term  used  for  the  process  of  detecting 
and  eliminating  faults  in  programs. 

decomposition  -  the  process  of  breaking  an  element  into 
smaller  pieces,  each  of  which  can  be  further  decomposed 
independently  of  the  others. 

default  -  one  of  a  set  of  alternative  values  or  options  that 
is  assumed  when  none  has  been  specified. 

derivation  -  a  micro  relation  which  provides  the  ability  to 
relate  data  objects  because  one  is  explicitly  derived  from 
another . 

design  -  the  creative  activity  of  describing  a  system  through 
tne  techniques  of  abstraction  and  decomposition.  Abstrac¬ 
tion  is  used  to  suppress  all  but  those  details  needed 
to  understand  the  design  at  a  specific  level.  Decomposi¬ 
tion  involves  dividing  the  system  into  pieces  (modules, 
programs  and  data  structures)  which  can  oe  related  in 
some  hierarchical  fashion.  The  resultant  design:  solves 
the  prooiera  posed  by  requirements,  is  consistent  with 
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crash  -  an  informal  term  for  the  abnormal  cessation  of  proc¬ 
essing  by  a  computer  system. 

creativity  aid  -  any  tool  or  technique  which  helps  to  develop 
an  idea. 

critical  path  -  the  shortest  path  in  a  precedence  network; 
the  path  that  represents  the  least  amount  of  a  critical 
resource  in  a  development  project. 

cursor  -  a  position  marker  on  a  video  display. 

cyclomatic  complexity  -  a  measure  for  complexity  which  uses 
graphs  to  study  control  flow.  (McCabe  [76] ) 

C3  -  command,  control  and  communication. 


DASD  -  contraction  for  direct  access  storage  device,  mag¬ 
netic  storage  devices  usually  based  on  disk  or  drum  tech¬ 
nology  and  allowing  direct  access  to  a  unit  of  data. 

data  base  -  the  set  of  data  required  by  an  application, 
function  or  system;  the  data  can  be  redundant  or  non- 
redundant  depending  upon  the  design  of  the  data  base;  the 
data  can  be  organized  hierarchically  (like  an  inverted 
tree),  or  relationally  (showing  how  data  is  related 
to  other  data),  or  as  a  network. 

data  base  management  system  or  DBMS  -  software  which  will 
store,  control  access,  retrieve,  manipulate,  update  and 
purge  information  from  a  data  base  shared  by  many  func¬ 
tions  or  applications  in  an  organization.  The  value  of 
a  DBMS  is  its  simplicity  to  the  user,  separating  the  log¬ 
ical  attributes  of  the  data  from  the  physical  attributes. 

A  DBMS  allows  the  user  to  concentrate  on  what  needs  to  be 
done,  while  the  DBMS  handles  all  I/O  operations  and  data 
manipulations.  A  DBMS  generally  includes:  a  data  mana _ e- 
raent  function  for  storing  and  controlling  access  to  data; 
a  data  dictionary  for  describing  the  data;  a  generalized 
query  language  for  retrieving  and  massaging  selective 
data;  and  a  report  generator  for  printing  massaged  data. 
The  separation  cf  logical  and  physical  attributes  permits 
programs  which  view  the  data  logically  to  remain  unchanged 
when  the  physical  structure  of  the  data  is  changed. 

data  binding  -  a  relationship  whereby  a  program  modifies  a 
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requirements  have  been  met  by  the  subsequent  specifica¬ 
tion,  i.e.,  that  no  inconsistencies  or  emissions  exist  in 
the  specification  which  should  be  expressed  in  a  formal 
language . 

complexity  -  the  sense  of  a  whole  having  many  intricate, 
interconnecting  parts. 

component  -  a  cart  or  element  of  a  whole;  software  components 
are  invariably  complex  parts  within  complex  subsystems 
within  complex  systems. 

concatenation  -  the  process  of  connecting  two  or  more  strings 
in  a  specific  order,  e.g.,  CA  concatenated  with  BD  yields 
CABD. 

configuration  -  the  relative  arrangement  of  components  in 
a  system. 

configuration  management  or  CM  -  a  management  activity  which 
controls  the  changes  made  to  a  frozen  (or  "baseline") 
component  or  system,  and  thus  protects  it  from  unauthor¬ 
ized  alteration. 

control  flow  analysis  -  a  methodology  for  analyzing  the 
structure  of  control  decision  points  within  software. 

control  structure  -  a  small  set  of  logic  elements  used  to 
create  proper  programs;  a  proper  program  has  one  entry 
point,  one  exit  point  and  well-defined  input  and  output; 
DO,  DO-WHILE,  DO-UNTIL,  I F-THEN- ELS E ,  and  CASE  are  com¬ 
monly  considered  the  basic  control  structures. 

conversion  -  the  process  of  changing  from  one  C3ta  process¬ 
ing  system  to  another,  usually  with  a  different  instruc¬ 
tion  set  architecture. 

correctness  -  the  concept  that  a  software  product  satisfies 
its  functional  and  interface  specifications;  correctness 
is  an  objective  to  be  balanced  against  other,  sometimes 
contradictory ,  objectives  but  should  be  considered  a 
necessity  in  the  development  of  all  software. 

correctness  analysis  -  a  comprehensive  set  of  methodologies 
to  ensure  that  software  correctly  implements  its  specifi¬ 
cation  and  that  faults  are  detected  and  removed  soon 
after  they  are  introduced. 
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character  set  -  an  agreed-upon  set  of  elements  used  to  rep- 
recent,  control,  or  organize  data;  ASCII  and  EBCDIC  ,vu 
examples  of  standardized  character  sets. 

CMS-2  -  Compiler  Monitor  System-2;  a  Navy  standard  program 
which  translates  the  source  statements  of  the  problem- 
oriented  or  high-level  CMS-2  language  into  ooject  code. 

CDR  -  Critical  Design  Review;  a  review  of  the  detailed  design 
of  an  element  of  software  held  when  detailed  design  is 
complete . 

code  -  loosely,  a  computer  program;  the  term  may  represent: 
(1)  the  original  instructions  (source  statements);  or  i 2 ) 
the  resultant  instructions  created  by  compiling  and 
assembling  the  source  statements  into  executable  object 
code;  or  (3)  the  act  of  creating  (coding)  a  computer 
program — this  last  use  of  code  includes,  loosely,  che 
activities  of  detail  design,  code  and  unit  test. 

code  translator  -  software  which  converts  programs  from  one 
programming  language  to  another  programming  language. 

command  language  or  CL  -  a  source  language  consisting  of 
operators  which  evoke  functions  to  be  executed. 

commonality  -  the  concept  that  similar  function  exists  in 
every  software  system. 

compatibility  -  the  concept  that  different  computers  can  run 
the  same  software  without  appreciable  alteration  of  the 
program. 

compilation  -  the  transformation  of  a  program,  written  in  a 
problem-oriented  language,  into  an  equivalent  programming 
language  which  is  oriented  to  a  specific  machine;  the 
original  program  may  be  compiled  independently  of  the 
transformed  program,  which  is  usually  processed  by  an 
assembler. 


compilation  units  -  separate  units  of  a  connected  set  of 
software  programs  which  may  oe  compiled  independently. 

compiler  -  software  used  to  transform  source  programs  into 
another  programming  language  closer  to  the  machine. 

completeness  analysis  -  the  technique  of  ensuring  that  all 
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batch  processing  -  the  processing  of 
eni “ s  or  i n  format  ion  e.g.,  a  set 


accumulated,  similar 
of  c  a  \  ..oil  records. 


bit  -  contraction  for  binary  digiT;  a  unit  of  information 
that  has  one  of  two  values,  either  0  or  1. 


OLack-oox  -  a  technique  which  uses  only  external,  observ¬ 
able  attributes’  the  input  i.s  known,  the  resulting 
output  can  be  observed,  and  the  internal  workings 
are  not  considered. 

block  diagram  -  a  diagram  of  a  system  in  which  principal 

pacts  are  represented  by  standardised  geometric  shapes  to 
she-  the  basic  • unctions  and  interrelationships. 


i read hoard  -  a  technique  used  to  prepare  an  early  working 
model  or  prototype;  engineers  once  used  yellow  wire  and 
blank  circuit  boards  'or  breadboards;  tc  design  circuits. 


breakpoint  -  a  place  in  a  program  where  its  execution  may  se 
externally  examined,  modified,  and  execution  resumed  or 
s topped  . 


buffer  -  a  storage  area  used  to  compensate  for  the  difference 
in  speed  between  two  functions  or  I/O  devices  during  the 
movement  of  data. 


bvte  -  a  sequence  of  adjacent  binary  digits  (bits)  operated 
on  as  a  unit,  and  usually  shorter  than  a  computer  word; 
a  byte  usually  contains  eignt,  and  sometimes  six,  bits. 


capacity  -  a  measure  of  processing  rate;  the  amount  of  data 
that  can  be  contained  by  a  data  storage  device. 

change  request  ‘-.racker  -  a  tool  designed  to  simplify  the 
control  of  change  requests  as  they  are  entered,  tracked 
and  resolved. 

channel  -  in  information  theory,  that  part  of  a  communica¬ 
tion  system  which,  connects  the  message  source  with  the 
message  sink. 
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assertion  -  a  formal  statement  about  the  function  of  a  code 
segment;  assertions  can  be  used  for  formal  proofs  of  cor¬ 
rectness  or  for  dynamic  verification  during  execution. 

assertion  analyzer  -  a  verification  tool  which  allows  embed¬ 
ding  of  assertions  in  code;  dynamic  analysers  verify  the 
assertions  against  actual  software  execution;  static  ana¬ 
lyzers  verify  for  syntactic  or  semantic  correctness. 

association  -  a  micro  relation  used  to  relate  data  objects 
explicitly  where  che  relationship  is  not  obvious,  such  as 
a  performance  model  with  a  -pecific  system  design. 

audit  -  a  methodical  examination  and  review  for  a  stated 
purpose . 

automatic  structurer  -  a  tool  which  transforms  unstructured 
code  into  structured  code. 


background  -  the  low-p’  . ity  mode  provided  by  an  operating 
system;  see  foreground  for  a  mere  complete  definition  cf 
foreground  and  background. 

background  job  -  a  job  which  is  run  by  the  operating  system 
in  a  low  priority  (background)  mode  when  system  resources 
are  not  being  completely  used  by  the  high  priority  fore¬ 
ground  mode,  and  the  resources  are  available  for  use  by 
the  background  mode. 

background  job  stream  -  a  sequence  of  queued  jods  which  are 
started  and  processed  automatically  by  the  operating  sys¬ 
tem. 

backup  -  a  copy  of  an  original  file,  data  base  or  system, 

which  is  kept  as  a  safeguard  against  the  loss  of  the  orig¬ 
inal  . 

baseline  -  the  body  of  lata  about  a  system  which  defines  it 
at  a  specif'c  point  in  *ime,  such  as  Release  1.1  as  of 
12/19 -SI;  t.ne  body  of  data  against  which  changes  can 
occur  under  management  control. 


f  its:  arm :  r.c  sou:  ce  a  to 
: ho  use  of  assembler  software. 
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abstract  data  -  data  with  non-specific  attributes;  see 
abstract  data  type. 

ibstract  data  type  --  a  concept  which  assigns  to  data  a  set 
of  high-level,  abstract  attributes  (allowable  operations 
and  tests),  until  it  can  be  given  more  specific  attributes 
by  the  process  of  stepwise  refinement. 

abstract  interface  -  a  concept  which  reveals  only  the  infor¬ 
mation  needed  to  use  an  interface  and  nothing  else;  a 
black-box  definition. 

abstract  machine  -  any  combination  of  hardware  and  software 
which  provides  different  characteristics  than  either 
alone;  a  concept  that  a  machine  is  the  total  of  its  hard¬ 
ware  and  its  software. 

abstraction  -  the  process  of  focusing  on  selected  qualities 
of  a  complex  subject  by  suppressing  all  but  those  details 
needed  to  understand  the  design  at  a  selected  level. 

access  controls  -  a  mechanism  for  determining  wno  can  access 
what  data,  and  what  operations  can  be  performed  on  that 
data. 

acquisition  management  model  or  ACM  -  a  life  cycle  model  used 
to  plan  and  manage  all  activities  for  the  development  of 
software  systems. 

activity  -  a  category  of  related  tasks  from  the  software 

engineering  process;  the  term  activity  is  synonymous  with 
the  phrase  "life  cycle  activity." 

Ada  -  a  modern  high-order  language  for  programming  which  will 
become  the  standard  language  for  DOD's  mission  critical 
applications. 

adaptation  -  the  process  of  making  changes  to  existing  soft¬ 
ware  either  to  add  new  function  or  to  correct  an  embedded 
fault;  adaptation  is  comparable  to  the  more  common  term 
"maintenance"  or  the  Navy  term  "in-service  engineering;" 
it  is  not  comparable  to  the  term  "life  cycle  support" 
which  includes  all  activities  in  the  life  cycle  of  soft¬ 
ware. 

alphanumeric  display  -  a  device  designed  to  display  alpha- 
•  i  me’  i  ■:  ( P  'o  Z  0  to  9 characters  plus  a  1 :  mi  ted  set  of 
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further  use. 

semantic  model  -  a  description  of  the  elements  of  a  user’s 
environment  and  its  specific  requirements,  using  a 
rigorously-defined  syntax  for  categorizing  terms  and 
establishing  relations  among  the  categorized  terms. 
Requirements,  once  they  are  precisely  defined  in  a  formal 
syntax  and  recorded,  can  be  analyzed  with  a  variety  of 
semantic  information  tools. 

set  -  a  fundamental  concept  in  mathematics  of  a  well-defined 
list,  collection  or  class  of  objects.  The  objects  in 
sets  are  called  the  elements  or  members  of  the  set  and 
can  be  anything:  people,  rivers,  dates,  numbers,  etc. 

SHARE/7  -  a  multiprocessor  time-sharing  system  hosted  on 
AN/UYK-7  computers. 

simulation  -  a  technique  for  dynamically  evaluating  a  design 
before  implementation  is  started;  simulation  requires  a 
model  and  a  simulator. 

simulator  -  a  tool  for  simulation. 

software  -  Broadly  defined:  the  information  needed  to  per¬ 
form  a  desired  function  on  a  computer  (the  "hardware"). 
Software  includes  the  sequence  of  instructions  to  be  exe¬ 
cuted  on  the  computer,  the  related  data  for  the  sequence 
of  instructions,  and  the  instructions  for  the  operating 
system.  (Note  that  the  application  data  to  be  trans¬ 
formed  by  the  function  is  not  included  in  the  definition 
nor  is  documentation  such  as  user  and  operator  instruc¬ 
tions.  )  Narrowly  defined:  that  sequence  of  executable 
computer  instructions  and  related  data  needed  to  control 
the  execution  of  a  computer  to  perform  a  desired  function. 
The  executable  instructions  must  be  in  a  form  suitable  for 
loading  into  a  computer;  these  instructions  then  control 
the  sequence  of  instructions  needed  to  perform  the  func¬ 
tion.  Related  data  can  be  either  real  or  abstract.  Real 
data  has  actual  content  and  can  be  manipulated,  e.g., 
AVERAGE  =  1 j . 4 67  or  DATE  *  1  MAY  1982.  Abstract  data 
defines  what  the  data  looks  like,  i.e.,  its  form  and 
structure.  (Notes:  The  term  "related  data"  does  not 
include  application  data.  The  narrow  definition  of  soft¬ 
ware  is  an  attempt  to  be  unambiguous  and  implies  that 
software,  in  its  purest  sense,  cannot  be  seen  nor  touched; 
it  also  excludes  instructions  for  the  user  and  operator's 
instructions.  ) 
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software  development  -  a  phase  of  the  software  life  cycle 
including  requirements  analysis,  specification,  design, 
implementation,  correctness  analysis,  and  management. 

software  component  -  a  general  term  for  software  which  per¬ 
forms  a  specific  function  and  has  a  unique  identifier; 
component  can  refer  to  a  system,  a  subsystem,  a  routine, 
or  a  segment  of  code. 

software  engineering  -  a  discipline  based  on  sound  engi¬ 
neering  principles  and  proven  methodologies,  for  creating 
software  that  is  correct,  reliable  and  economical;  the 
application  of  repeatable  methodologies  and  proven  disci¬ 
plines  to  the  design  and  implementation  of  software. 

software  engineering  process  -  the  overall  set  of  activities, 
applied  throughout  the  life  cycle  of  software,  which  pro¬ 
duces  the  required  information  needed  at  the  interfaces 
of  each  life  cycle  activity. 

source  statements  -  the  original  sequence  of  instructions  for 
a  unit  of  software  (usually  written  in  a  high-level  lang¬ 
uage)  before  it  is  transformed  into  object  modules. 

specification  -  the  product  of  requirements  analysis  which 
transforms  the  less  rigorous  system  requirements  into  a 
rigorous  description  of  the  external  view  of  a  system. 

SSF  -  Software  Support  Facility,  a  proposed  NAVELEX  software 
production  facility. 

standards  checker  -  a  static  analysis  tool  which  examines 
code  and  documentation  for  violations  of  standards. 

state  machine  -  a  function  defined  in  terms  of  state  transi¬ 
tions  which  transforms  a  state  with  input  into  a  new 
state  with  output.  More  formally;  a  function  (set) 
whose  members  are  ordered  pairs  of  ordered  pairs; 
m  *  [(x,  y),  (u,v) ]  ,  where  each  member  of  m  has  the 
interpretation  ((<state>,  <input>),  (<next  state>, 

<output> ) ) . 

static  analysis  -  analysis  techniques  which  involve  a 

detailed  manual  examination  of  an  item;  the  correctness 
analysis  activity  used  three  static  analysis  techniques, 
here  given  in  order  of  increasing  rigor:  reviews, 
inspections  and  proofs  of  correctness. 
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stepwise  refinement  -  the  process  of  decomposing  a  unit 

into  successive  levels  of  greater  and  greater  detail;  each 
decomposition  is  checked  for  correctness  before  c< t  i  au  i.g 

to  the  next  lower  level. 

structured  design  -  a  methodology  for  creating  a  design: 
data  flow  diagrams  are  analyzed  and  the  structure  is 
derived  by  applying  design  rules  and  guidelines. 

structured  programming  -  a  programming  technique  which 

views  a  program  as  a  functional  composition  of  a  finite 
small  set  of  one-in  one-out  control  structures. 

stub  -  a  component  which  simulates  the  functioning  of  a  sub¬ 
ordinate  component  during  testing  of  the  superior  com¬ 
ponent. 

support  system  -  a  set  of  tools  (preferably  integrated) 
which  are  designed  to  aid  software  engineers  in  manipu¬ 
lating  information  on  a  data  base. 

symbolic  execution  -  a  technique  for  proving  the  correctness 
of  certain  classes  of  programs  by  executing  them  symbol¬ 
ically  to  prove  certain  assertions. 

synchronous  -  two  or  more  processes  that  depend  upon  the 
occurrence  of  a  specific  event;  having  a  regular  or  con¬ 
stant  time  interval. 

syntax  -  the  rules  concerning  the  pattern  or  structure  of 
the  word  order  in  a  formal  language. 

syntax  checker  -  a  tool  for  examining  statements  and  val¬ 
idating  their  correctness  against  the  rules  of  the  formal 
language. 

system  generation  or  SYSGEN  -  the  process  of  selecting 
optional  software  components  and  creating  a  particular 
operating  system  configuration  for  a  specific  installa¬ 
tion. 

system  test  -  an  independent  verification  that  the  system 
meets  specifications. 


target  computer  -  the  computer  system  which  executes  ECS 
software. 
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table-driven  code  -  code  whose  execution  is  controlled  by 
entries  in  a  table  or  set  of  tables. 

test  -  execution  of  a  system  (or  component)  with  known 
input  to  a  known  environment  with  expected  results. 

test  data  generator  -  a  tool  which  automatically  generates 
test  data  based  on  the  design  (or  the  code)  and  additional 
instructions  such  as  "test  every  path  through  'A'." 

test  case  -  data  designed  to  test  a  single  path  of  a  software 
component. 

test  harness  -  a  tool  whicn  provides  a  framework  for  testing 
small  units  of  code;  it  is  an  interactive  tool  for  defin¬ 
ing  the  procedure  interface,  preparing  test  data,  running 
the  instrumented  test,  and  displaying  the  test  results. 

text  editor  -  a  tool  for  creating  and  manipulating  prose  in 
machine-readable  form. 

throughput  -  a  measure  of  the  speed  with  which  a  computer 

system  will  process  a  unit  of  work  from  a  mix  of  jobs  from 
input  through  output. 

throwaway  cede  -  the  creation  of  code  to  prove  a  design  but 
which  may  have  to  be  discarded  because  of  what  is  learned 
from  the  creation  of  the  first  version;  analogous  to  bread¬ 
boarding  in  hardware. 

time  tag  -  the  time-of-day  and  date  information  appended  to 
data. 

tool  -  a  tool,  in  this  document,  is  a  computer-based  mecha¬ 
nism  that  either  stimulates  the  creative,  intellectual 
process,  or  else  automates  a  clerical  process;  it  is 
a  mechanism  used  to  perform  all  or  part  of  a  methodology. 

tool  atoms  -  building  blocks  which  alone  perform  no  useful 
task  but,  in  combination  with  other  tool  atoms,  can  be 
used  to  create  useful  tools. 

tool  kit  approach  -  an  approach  to  software  engineering 

wherein  a  set  of  tools  (possibly  integrated)  is  provided 
to  the  software  engineer  but  no  constraints  are  implied 
on  the  choice  of  methodologies  or  tools  to  be  used. 
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top-down  implementation  -  an  incremental  implementation 
approach  stressing  the  creation  of  an  operable,  but 
skeletal,  system  early  in  the  life  cycle;  since  the  sys¬ 
tem  always  works,  stubs  can  be  replaced  with  their  com¬ 
pleted  component,  and  the  system  retested  with  all  effort 
focused  on  integrating  only  one  component;  top-down  imple¬ 
mentation  allows  one  to  deal  with  a  single  component's 
problems  more  gracefully,  and  eliminates  the  need  for 
drivers  but  requires  stubs. 

traceability  -  a  micro  relation  which  provides  the  ability 
to  follow  a  requirement  as  it  impacts  specification, 
design,  code  and  other  baseline  products. 

tree  -  an  acyclic  directed  graph  starting  from  a  single  node. 

trouble  report  or  TR  -  a  mechanism  for  describing  a  defect 
and  tracking  it. 

TSSS  -  Trident  Software  Suport  System;  an  ECS  software 
development  system  using  standard  commercial  software 
and  hardware  and  supporting  code  generation,  unit  test 
and  documentation. 

Type  A  specification  -  states  the  technical  and  mission 
requirements  for  a  system  as  an  entity,  allocates 
requirements  to  functional  areas,  and  defines  the  inter¬ 
faces  between  or  among  the  functional  areas. 

Type  B  specification  -  requirements  for  the  design  or  engi¬ 
neering  development  of  a  product  (system  component)  dur¬ 
ing  the  development  period. 


unit  test  -  the  testing  of  the  lowest  unit  of  software 

independently  of  other  programs  which  interract  with  it. 

uses  hierarchy  -  a  hierarchy  of  modules  wherein  the  relations 
of  higher  level  modules  to  lower  level  modules  is  one  of 
dependency,  wherein  the  related  lower  level  modules  must 
correctly  implement  their  respective  specifications  in 
order  for  the  higher  level  module  to  function  properly. 


validation  -  an  activity  that  assures  that  each  product 
reflects  the  requirements  and  specifications  applicable 
to  it. 
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verification  -  a  process  that  assumes  that  a  product  imple¬ 
ments  its  design. 

version  -  a  variation  of  a  release;  a  macro  relation  which 
identifies  varying  current  implementations  of  a  system 
which  may  be  required  to  support  multiple  (but  slightly 
different)  physical  installations;  a  micro  relation  which 
identifies  the  mutation  of  a  data  object. 


Warnier-Orr  diagram  -  a  graphic  technique  for  displaying 
control  flow  in  software. 

WBS  -  work  breakdown  structure  -  a  technique  of  decomposing 
tasks  into  sub-tasks  with  resource  and  personal  assignment 
of  responsibilities. 

white-box  -  a  testing  technique  which  uses  knowledge  of  the 
internal  design  of  a  program,  i.e.,  the  input  is  known, 
the  internal  workings  of  the  program  is  known,  and  the 
resulting  output  can  be  observed. 


6.2  -  Program  6.2  for  Exploratory  Development  within  the 
Navy's  RDT&E  (Research,  Development,  Test  and  Evolution) 
accounts. 


stract  data  type  -  I:  34;  II:  52;  G:  1. 
abstract  data  structure  -  I:  30-31;  II:  6. 
abstraction  -  I:  2,  29-30,  32;  G:  1. 
acquisition  management  model  -  I:  12-14;  G:  1. 

Ada  -  Intro:  1,  3;  I:  37,  39-40;  II:  53,  60-61;  G:  1. 
adaptation  -  I:  2,  22,  31;  II:  1,  9,  36;  G:  1. 
ancestry  -  II:  24;  G:  2.  % 

application  paradigm  -  II:  21,  57-58;  G:  2. 
application  skeleton  -  Intro:  4;  I:  56-57;  G:  2. 
architecture  -  II:  27,  38,  60-61;  A:  3,  11;  G:  2. 
assertion  analyzer  -  I:  47-48;  II:  54;  G:  3. 
audit  -  I:  52;  G:  3. 

background  -  Intro:  1-3,  7;  II:  34,  39,  41;  G:  3. 

black-box  -  I:  45-47;  G:  4. 

commonality  -  I:  56;  II:  3;  A:  11;  G:  5. 

completeness  analysis  -  I:  27-28;  A:  4;  G:  5. 

configuration  management  -  I:  9,  16,  49,  52-53,  55;  II:  5,  9, 

20,  33;  G:  6. 

control  structure  -  I:  37-38;  II:  29,  45;  G:  6. 

correctness  analysis  -  Intro:  5;  I:  4,  6-7,  12-13,  15,  25,  27,  30, 

41-50,  52;  II:  14,  54,  56;  A:  4;  G:  6. 
critical  path  -  I:  53-54;  G:  7. 
cyclomat ic  complexity  -  I:  35;  G:  7. 

data  base  management  system  -  I:  23,  37,  56;  II:  20,  40,  60;  G:  7. 
data  binding  -  I:  35;  G:  7. 

data  dictionary  -  I:  20-21,  23;  II:  43,  52;  G:  8. 
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data  structure  -  I:  23,  29-31,  34;  II:  6?  G:  8. 
decomposition  -  I:  29,  30-34,  44;  II:  52;  G:  8. 
derivation  -  II:  26;  G:  8. 
dynamic  analysis  -  I:  44,  49;  G:  9. 

error  -  I:  6,  12,  28-29,  33,  36,  39-41,  49-50;  II:  4,  7,  14, 
20,  30,  32,  40-41,  45,  59,  62;  G:  10. 


error-day  - 

I:  41,  44 

;  G: 

10. 

estimation 

model  -  I: 

24; 

II: 

55; 

G 

:  10. 

executable 

design  -  I 

:  9, 

46; 

G: 

10 

• 

feasibility 

analysis 

-  I: 

21- 

22; 

G: 

11. 

HDM  -  A:  12 

;  G:  12. 

hierarchic 

-  II:  13, 

22-23;  G 

:  12 

• 

high-level 

language  - 

I: 

24, 

38; 

G: 

12. 

information 

-hiding  — 

I:  30-31 

,  34 

• 

t 

II:  52;  A:  12;  G: 

13. 

inspection 

-  I:  44-45 

.  47 

,  49 

,  52 

« 

r 

11:33,  54;  G:  13. 

integration 

-  Intro: 

1;  I 

•  4, 

7-8 

f 

12-13,  37-38,  49; 

II:  48; 

G:  13. 

interface  - 

Intro:  2, 

4, 

5-6; 

I: 

26 

,  30,  33,  48-50, 

56;  II: 

6,  27-39, 

42, 

48, 

57- 

58 

,  60-62;  G:  13. 

macro  relat 

ions  -  II: 

4, 

22-23;  G 

• 

• 

15. 

mailbox  -  II:  11;  G:  15. 

mapping  -  I:  20,  26;  G:  15. 

micro  relations  -  II:  4,  22-26,  40;  G:  15. 

model  -  I:  2,  4,  6-9,  12-13,  15-16;  II:  11,  25,  55;  A:  11;  G 
non-procedural  -  Intro:  4;  II:  29-30;  G:  16. 
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patch  -  IT:  7;  G:  17. 


PDL  -  I:  30,  32-35; 

II: 

6,  45,  52, 

56, 

60; 

G:  17. 

performance  -  I:  2, 

13, 

19,  21-22, 

24, 

28, 

35-37,  40,  46-47, 

49;  II:  2,  22,  25-27,  34,  37,  54,  58-59,  62;  G:  17 
pipelining  -  II:  30,  40,  48-49,  56,  62;  G:  18. 

POD  -  II:  60;  A: 12;  G:  18. 
portability  -  II:  27,  49. 

productivity  -  Intro:  1-4;  I:  4,  7,  38,  50,  55-56;  II:  57; 

A:  1,  4,  6;  G:  19. 

program  skeleton  -  II:  21,  57;  G:  19. 

proof  -  I:  27,  44-45,  47-49;  II:  9,  54;  A:  12;  G:  19. 


prototype  -  I:  9, 

24, 

46; 

M 

M 

12,  50; 

A:  12;  G:  19. 

quality  assurance 

-  I: 

9, 

52, 

55;  II: 

9;  A:  4;  G:  20. 

redirection  -  II: 

16, 

18, 

40; 

G:  20. 

relational  -  I:  22-23,  25;  II:  22-24;  G:  20. 

reliability  -  Intro:  1-3,  I:  1,  6,  38,  47,  49,  55;  II:  16,  18, 


54,  58;  A:  4;  G:  21. 

requirements  analysis  -  Intro:  4-5,  I;  4,  6,  8,  12-13,  18-19, 

22-28;  A:  5;  G:  21. 


reusable 

component 

-  Intro:  4; 

II: 

57; 

A:  4-5; 

G: 

21. 

review  - 

I:  13,  15, 

44-45,  47, 

52, 

55; 

II:  11; 

A: 

2;  G:  21. 

SADT  -  I:  20,  33;  G:  22. 

SCR  -  A: 12 ;  G:  22. 

semantic  -  I:  19-27;  II:  5,  12,  16-17,  24,  26,  50,  56,  62;  G:  22 
static  analysis  -  I:  44,  48-49;  II:  7,  13;  G:  24. 
stepwise  refinement  -  I:  32,  34;  II:  52;  G:  25. 
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|  structured  design  -  I:  32;  G:  25. 

j  structured  programming  -  I:  37,  39;  II:  45;  G:  25. 


,  symbolic  execution  -  I:  47-48;  II:  54;  G:  25. 

system  generation  -  I:  37-38,  40;  II:  4,  20;  G:  25. 
system  test  -  I:  4,  46,  50;  II:  8,  37,  54;  G:  25. 
top-down  -  I:  38;  II:  53;  G:  27. 

traceability  -  I:  16,  20,  22,  26,  29;  II:  6,  23-24,  26-27;  G:  2~. 

]  uses  hierarchy  -  I:  32,  34;  II:  52;  G:  27. 

i 

verification  -  I:  6,  8;  A:  12;  G:  28. 

|  version  -  I:  4,  6,  9,  31,  36;  II:  7,  18-20,  22-24,  37;  G:  28. 

j  white-box  -  I:  45-46;  G:  28. 
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Hie  logo  for  the  Novy  Standard  Software  Engineering  Environment 
(NSSEE)  shows  a  sea  serpent  riding  the  crest  of  the  software  technology 
wave  and  breathing  structure  into  the  software  development  process 
(represented  by  the  well-ordered  field  of  ones  and  zeros).  NSSEE  should 
be  pronounced  "Nessie"  in  honor  of  a . lake-dwelling  resident  of  the  British 
isles.  History  does  not  record  any  interaction  between  Nesaie  and  another 
well-kncwn  British  citizen,  Ada.  Hie  modem  Ada  and  NSSEE.  will  be  well- 
aaquainted,  however. 


PREFACE 


This  is  one  of  a  set  of  documents  resulting  from  the 
work  of  the  Naval  Material  Command's  Software  Engineering 
Environment  Working  Group  ( SEEWG ) .  The  set  includes  an 
■Executive  Summary,"  "Framework  for  a  Navy  Standard  Soft¬ 
ware  Engineering  Environment,"  and  "Evolution  Plan  for  a 
Navy  Standard  Software  Engineering  Environment." 

The  Framework  document  provides  a  basis  on  which  to 
plan  and  develop  a  standard  methodology-driven  software 
engineering  environment  for  the  Navy.  The  Evolution  Plan 
describes  a  strategy  for  transition  to  a  standard  software 
engineering  environment  and  also  the  evolution  of  the 
environment  itself. 

These  documents  represent  the  culmination  of  the  first 
phase  of  an  effort  to  develop  standard  tools  and  procedures 
to  support  development  of  software  for  Navy  embedded  computer 
systems.  It  is  intended  ultimately  to  implement  a  standard 
software  engineering  environment  encompassing  the  whole 
software  life  cycle  and  supporting  effective  use  of  the  Ada 
programming  language.  In  the  interim,  these  documents  will 
provide  a  basis  for  co-ordinating  decisions  with  respect  to 
improvements  to  existing  software  support  systems. 


FOREWORD 


This  document  contains  the  outline  pertaining  to  the 
evolution  to,  and  evolution  of,  a  Navy  Standard  Software 
Engineering  Environment  (NSSEE ) .  An  expansion  of  this 
outline  into  a  finished  document  will  be  completed  by 
October,  1982.  The  work  was  done  for  the  NAVMAT  Software 
Engineering  Environment  Working  Group  (SEEWG). 

The  principal  investigator  in  this  effort  was  Robert  N. 
Charette,  Naval  Underwater  Systems  Center,  Newport,  Rhode 
Island.  Others  that  reviewed  this  document  and  provided 
valuable  inputs  were:  LCDR  K.  Paige  (PMS  408),  T.  P.  Conrad 
(NUSC) ,  T.  E.  Dawson  (NUSC),  G.  Bain  (NUSC),  R.  Bouse 
(NUSC),  T.  Phillips  (NOSC),  H.  Stuebing  (NADC),  S.  Peele 
(FCDSSA) ,  and  C.  Russ  (FCDSSA). 
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I.  INTRODUCTION 


Construction  of  a  Software  Engineering  Environment 
(SEE)  for  the  Navy  will  be  a  very  difficult  task.  It  will 
require  several  orders  of  magnitude  more  effort  than  that 
which  will  be  expended  to  implement  Ada.  Therefore,  a  plan 
is  needed  to  evolve  user  and  application  projects/software 
support  systems  into  a  SEE,  and,  while  the  SEE  is  evolving, 
to  allow  these  groups  to  make  use  of  software  engineering 
concepts  as  they  are  developed. 

This  document  is  one  of  a  series  produced  by  the  NAVMAT 
Software  Engineering  Environment  Working  Group  (SEEWG). 

The  first  document,  "Framework  for  a  Navy  Standard  Software 
Engineering  Environment,"  presents  the  goal  of  a  standard 
software  engineering  environment  in  tetms  of  the  methodol¬ 
ogies  and  tools  required  to  support  the  Navy’s  software 
life  cycle  model.  The  second  document,  a  "Strategy  Docu¬ 
ment,"  discusses  the  programmatic  issues  of  how  to  establish 
and  manage  a  SEE.  This  programmatic  information  is  con¬ 
tained  in  a  memorandum  from  the  SEEWG  to  MAT  Q8Y  and  is 
not  available  for  general  review.  The  "Evolution  Document" 
discusses  the  technical  issues  and  policies,  standards, 
and  guidelines  necessary  to  transition  to  a  NSSEE,  as  well 
as  the  subsequent  evolution  of  a  NSSEE. 
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II.  EVOLUTION  TO  A  NAVY  STANDARD  SOFTWARE  ENGINEERING 
ENVIRONMENT  (NSSEE) 


A.  Technical  Approach 

1.  Description  of  the  Evolution  Plan 

a.  Constraints 

i)  The  NSSEE  is  to  be  based  on  the 
MAPSE.  The  MAPSE  effort,  pro¬ 
ducing  a  minimal  set  of  tools 
to  support  Ada,  will  yield  the 
Navy's  most  modern  standard 
software  engineering  tool  set. 

It  is  the  most  appropriate 
starting  point  for  the  evolu¬ 
tion  of  a  NSSEE. 

ii)  Existing  application  projects 
and  support  systems  cannot  be 
ignored  and  must  be  able  to 
benefit  from  the  concepts  and 
products  resulting  from  each 
step  in  the  development  of  the 
NSSEE. 

b.  Plan  Outline 

i)  The  life  cycle  model  in  the 
document  "Framework  for  a  Navy 
Standard  Software  Engineering 
Environment"  defines  several 
life  cycle  activities.  The 
interface  between  activities 
will  be  defined  by  the  Navy  in 
an  interface  specification 
document  controlled  by  the  Navy. 

ii)  The  Navy  will  build  at  least 
one  integrated  tool  set  that 
will  operate  through  all 
activities  and  interfaces. 

These  tools  and  interfaces  will 
comprise  the  NSSEE.  A  minimal 
tool  set  necessary  to  produce 
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baselined  data  at  each  life  cycle 
activity  interface  will  be  pro¬ 
vided.  The  completeness  of  the 
interface  definition,  coupled 
with  the  ability  of  the  provided 
tool  set  to  satisfy  these  inter¬ 
faces,  should  eliminate  the 
necessity  of  using  any  tools 
other  than  those  provided 
within  the  NSSEE.  However,  the 
NSSEE  will  incorporate  supple¬ 
mentary  tools  for  each  life 
cycle  activity  that  may,  depend¬ 
ing  upon  the  project,  be  benefi¬ 
cially  applied.  For  example, 
within  the  "specification" 
activity,  Figure  1,  a  language 
analyzer  tool  is  provided  as 
well  as  one  (or  possibly  several) 
modeling  tools  and  consistency/ 
completeness  analysis  tools. 

Thus,  within  the  NSSEE,  there 
will  exist  flexibility  for 
tailoring  tool  selection  to 
satisfy  application  dependent 
needs  and  still  meet  interface 
standards. 

2.  Implementation  Issues  of  a  NSSEE 

a.  An  incremental  approach  will  be  used 
to  develop  the  NSSEE  with  the  Navy 
MAPSE  as  the  first  increment.  Ini¬ 
tially,  work  will  be  directed  at  the 
interface  point  that  is  known  best, 
i.e.,  the  code/test  interface.  The 
initial  definition  of  interface  require¬ 
ments  is  defined  in  "Framework  for 
a  Navy  Standard  Software  Engineering 
Environment"  under  the  heading  Base¬ 
lined  Products.  Figure  2  illustrates 
the  ’  ncremental  approach.,  shewing  the 
grewtn  of  both  tool  ne  and  interface 
data  requirements  until  th-  -  he 
life  cycle  is  support*? i  by  tne  NSS'-li'. 
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b.  Implementation  of  the  "complete" 

NSSEE  (as  defined  in  the  Framework 
document)  is  beyond  the  current  state- 
of-the-art,  thus,  research  efforts 
will  be  required.  Research  areas 
need  to  be  identified  and  prioritized. 
Areas  of  research  called  for  in  the 
Framework  document  include: 

-  methodology  (which  one(s)  to 
use  within  and  across  life 
cycle  activities). 

-  interfaces  (syntax,  semantics, 
numbers  of,  etc. ) . 

-  tools  (types  required,  build, 
buy,  etc.  ) . 

-  quality  assurance. 

-  software  reusability. 

c.  Impacts  of  Incremental  Approach 

i)  The  incremental  approach  provides 
the  benefits  of  a  standard 
software  engineering  environment 
in  the  near  term  while  providing 
for  the  phased  introduction  of 
the  results  of  R&D  efforts  as 
they  become  available.  It  also 
facilitates  the  graceful  migra¬ 
tion  of  current  application 
projects  and  support  systems  to 
the  NSSEE  by  providing  for  the 
gradual  adoption  of  standard 
products  and  procedures  as  they 
are  produced. 

ii)  As  new  interfaces  and  tools  are 
added,  there  may  be  unavoidable 
perturbations  on  previous  work 
completed  on  the  NSSEE.  Orderly 
expansion  and  careful  research 
efforts  should  help  minimize 
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these  impacts.  The  exact  nature 
of  this  expansion  and  under 
whose  supervision  are  unresolved 

issues. 

d.  The  issue  of  training/education  is 
very  important  for  managers,  devel¬ 
opers,  and  users  of  the  NSSEE.  The 
understanding  of  how  to  competently 
use  the  NSSEE  is  critical  to  any 
benefits  derived  from  it.  The  areas 
of  concern  are  training  new  and 
retraining  "old"  personnel  (both  gov¬ 
ernment  and  contractors)  and  making 
the  user  interface  into  the  NSSEE  as 
simple  as  possible.  To  alleviate 
these  concerns  the  following  will  be 
required : 

-  Complete  documentation  that  is 
tutorial  in  nature. 

-  A  human  engineered,  user- 
friendly  interface  for  the 
NSSEE. 

-  NAVMAT  supported  "Tiger  Teams" 
to  resolve  on-site  installation 
and  "learning  curve"  problems 
as  specified  in  the  Strategy 
Document. 

B.  Policies,  Standards,  and  Guidelines  to  support 
this  approach. 

1.  There  is  an  immediate  need  for  modification 
of,  or  additions  to,  existing  Policies, 

Standards,  and  Guidelines  in  or  dev  to 
have  <\  i. ■  a  ir.evo  t  k  ,n Jet  oh  i  “ h  u  "EGt'E  car. 
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a.  New  Policies,  Standards,  and  Guidelines 

recommended  are: 

i)  The  PDA  should  designate  PhS  4C6 
as  the  DA,  and  FCDSSASD  as  the 
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LCSA  (MAT  08Y  is  the  PDA)  for 
the  NSSEE. 

ii)  The  interface  specification 
should  be  a  basis  for  a  TADSTAND. 
However,  the  specific  character¬ 
istics  of  the  interface  must  be 
reflected  in  a  mil-standard. 

The  Framework,  document  should 
be  used  as  the  baseline  reference 
for  the  generation  of  a  Navy 
standard  software  engineering 
environment  TADSTAND. 

iii)  MAT  08Y  shall  promulgate 
"Framework  for  a  Navy  Standard 
Software  Engineering  Environment" 
as  a  companion  to  the  Embedded 
Computer  Resources  Master  Plan. 

iv)  MAT  08Y  should  use  the  Framework 
document  as  the  context  for  all 
decisions/plans  concerning  the 
NSSEE,  including: 

-  Coordinating  all  current 
and  future  software 
engineering  environment 
related  efforts. 

-  Research  and  development 
decisions . 

Once  the  NSSEE  has  been  specified 
and  implemented,  no  other  software 
engineering  environment  efforts 
will  be  undertaken  by  the  Navy, 
except  those  for  the  NSSEE. 

v)  Guidelines  for  coordination  with 
Joint  Logistics  Commanders'  and 
the  AJPO  work  are  required. 

These  are  discussed  more  fully 
in  the  Strategy  document. 


vi )  Standard  licensing  agreements 
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for  commercial  tools  that  may 
become  part  of  the  NSSEE  should 
be  drafted. 

vii)  The  n*.ed  for  a  waiver  from  OMB 
Circular  109  allowing  for  Navy 
prescription  of  software  engi¬ 
neering  tools  and  procedures 
on  contracted  software  acquisi¬ 
tions  should  be  investigated. 

b.  Existing  Policies,  Standards,  and 

Guidelines  that  may  require  modifica¬ 
tions  follow.  Specific  changes  and 
the  justifications  for  each  remain  to 
be  documented. 

i)  Acquisition: 

-  SECNAV  5000. 1A 

-  SECNAV  5200.32 

-  TADSTAND  2,  3,  9,  A,  B,  C,  D 

ii)  Documentation: 

-  SECNAVINST  3560.1 

-  TADSTAND  E 

iii)  Security/Privacy: 

-  OPNAVINST  5239.1 

-  OPNAVINST  5510. IP 

-  SECNAVINST  5211. 5B 


-  NAVMATINST  5510.17 
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v)  Transfer  of  Responsibility  for 
Navy  Tactical  System  Software: 

-  NAVMATINST  5200. 27A 

vi)  Update  the  Master  Plan  for 
Embedded  Computer  Resources 

Once  the  first  interface  specification  is 
approved  as  a  standard,  the  initial  ele¬ 
ment  of  a  NSSEE  exists.  Thus,  MAT  08Y 
must  determine  whether  it  will  allow 
waivers  from  this  standard  and  also 
whether  it  will  provide  funding  to  facil¬ 
itate  compliance  with  the  standard.  Dur¬ 
ing  the  transition  period,  prior  to  imple¬ 
mentation  of  the  full  NSSEE: 

a.  New  software  support  systems  (i.e., 
NSSEE  oriented  and  approved  projects) 
will  be  required  to  meet  this  standard. 

b.  Existing  software  support  systems, 
running  existing  application  projects 
(e.g.,  Share/7  supporting  MK117  FCS) 
should  be  considered  for  a  waiver 
from  this  standard  on  a  case  by  case 
basis  after  a  cost/benefit  analysis 
is  completed. 

c.  New  application  projects  will  be 
required  to  use  support  systems  that 
meet  the  standard.  If  it  is  desired 
to  use  old  support  systems  (e.g., 
avionic  system  "AIM-IX"  running  on 
FASP),  then  these  support  systems 
must  be  upgraded.  As  a  consequence 

of  this  approach,  these  new  application 
projects  will  be  able  to  migrate  more 
easily  to  support  systems  that  accom¬ 
modate  the  latest  iteration  of  the 
interface  standard. 

d.  Determining  compliance  with  the 
standard  interface  specification 
implies  an  “accreditation"  mechanism 
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of  some  type.  Accreditation  procedures 
(i.e.,  how  the  semantic  and  syntactic 
consistency  of  the  interfaces  is 
maintained),  and  who  is  respons icle , 
need  resolution. 

3.  In  time,  additional  interfaces  and  standard 
tools  will  be  incorporated  to  "flesh-out" 
the  skeleton  NSSEE.  MAT  08Y,  based  on 
recommendations  of  the  NSSEE  program  and 
management  organization  as  described  in 
the  Strategy  document,  will  then  need  to 
determine  which  support  systems  and/or 
application  projects  are  required  to 
upgrade  to  the  standard  tools  and  inter¬ 
faces. 

a.  New  application  projects  will  be 
required  to  use  the  standard  tools 
and  interfaces. 

b.  Contractors  will  be  required  to 
deliver  products  that  meet  the 
interface  specs,  but  not  necessarily 
to  use  the  standard  tools. 

c.  Existing  support  systems  will  be 
upgraded  on  a  case-by-case  basis. 

4.  After  a  "complete"  NSSEE  (as  defined  in 
the  Framework  documents)  is  available, 
all  new  Navy  projects  will  be  required  to 
use  it. 

j.  Mo  funding  for  upgrades  to  old  support 

s\ stems  will  be  allowed .  Th  i «  ensures 
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c.  Contractors  will  be  required  to  deliver 
products  that  meet  the  interface  speci¬ 
fications,  but  not  necessarily  be 
required  to  use  the  NSSEE.  This  will 
allow  contractors  to  be  innovative 
in  tool  selection  and  use  (e.g.,  to 
gain  or  maintain  a  "competitive  edge”) 
which  in  the  long  term  should  be 
beneficial  to  the  Navy.  The  NSSEE 
will  De  GEE  to  any  contractor  in 
response  to  direction  from  a  Navy 
sponsor. 

5.  Milestones 

A  schedule  of  milestones  for  the  develop¬ 
ment  of  the  NSSEE  and  applicable  policy 
and  standards  revisions  must  be  defined. 
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II.  EVOLUTION  OF  THE  NSSEE 

A.  Continued  evolution  of  the  NSSEE  is  required 
to  ensure  the  transfer  of  benefits  as  the 
technology  (hardware,  software  engineering 
systems,  etc.)  evolves,  experience  is  gained, 
and/or  requirements  change  as  shown  in  Figure  3. 

1.  The  sources  of  new  technology  will  be 
from  inside  and  outside  the  Navy  commun¬ 
ity,  as  described  in  the  Strategy  docu¬ 
ment.  The  "Not  Invented  Here"  and  "main¬ 
tain  the  status  quo"  syndromes  must  be 
avoided . 

2.  A  "software  change  control  board"  will  be 
incorporated  to  determine  how,  when,  and 
what  new  technology  should  be  added  to 
the  NSSEE. 

3.  Care  must  be  exercised  to  minimize  the 
probability  of  a  need  to  modify  the 
interface  standard.  All  Navy  projects 
using  the  NSSEE  may  have  to  be  upgraded 
if  the  interface  standard  is  modified. 

In  that  event,  procedures  must  be  devel¬ 
oped  to  facilitate  such  upgrades. 


